Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
olá, galera!
É o seguinte:
No php, quando geralmente utilizamos uma função nativa passando mais argumentos que o esperado, ele retorna um erro.
Exemplo:
echo strlen('string');//6 -- Aqui está tudo normal
Se eu fizer isso:
echo strlen('string', 'outro parametro não esperado');
é gerado esse erro:
Warning: strlen() expects exactly 1 parameter, 2 given in C:\xampp\htdocs\teste\index.php on line 4
Eu pensei em fazer a mesma coisa, mas gostaria de saber se fica bacana (ou se é recomendável)?
Fiz assim:
function minha_funcao($string)
{
if(func_num_args() > 1)
{
$message_error = sprintf('The User Function %s() expects exactly 1 parameter, %d given', __FUNCTION__, func_num_args());
return trigger_error($message_error, E_USER_WARNING);
}
return $string;
}// teste //
echo minha_funcao('uma string');
echo minha_funcao('uma string', 1);Vai gerar:
Warning: The User Function minha_funcao() expects exactly 1 parameter, 2 given in C:\xampp\htdocs\teste\index.php on line 13
Nesse caso, trigger_error() é para funções e throw new Exception é para método de classes?
De onde você leu/tirou isso?
De lugar nenhum, foi só uma dúvida mesmo. Imaginei que pelo fato de uma função não ter nada a ver com a orientação a objetos, trigger_error() fosse indicado.
Além de ser desnecessário fazer isso, você ainda está desperdiçando performance. strlen(), assim como todos os recursos que a linguagem oferece são escrito em C que é bem mais rápido que qualquer código escrito em PHP.
Nesse seu código, o interpretador tem de localizar a função quando invocada e executar uma condição. Se a condição se satisfizer então vai distribuir os valores nos respectivos placeholders de sprintf(), disparar um erro de difícil manipulação, já que trigger_error() é, a grosso modo uma forma de permitir ao programador disparar os mesmos erros que o PHP dispara.
Quanto a relação com Orientação a Objetos, Exceptions são infinitamente melhores porque com delas você consegue usar um ou mais blocos try...catch e obter a mensagem de erro a qual você pode não exibir diretamente ao usuário, mas gerar um log de erro para você, Administrador/Programador, por exemplo.
É possível, inclusive, que você automatize todo processo de Exceptions através de set_exception_handler(), função essa que te permite usar classes próprias para Exceptions.
Mais até! É possível que até mesmo os erros que o PHP disparar sejam convertidos em um ErrorException por utilizar set_error_handler() e, assim, também pegá-las com um catch.
Mas atente quem nem todos os erros que o PHP dispara podem ser convertidos em Exceptions por set_error_handler(). Os Fatal Errors "passam batido" sendo necessário utilizar register_shutdown_function(), como mostra esse stack.
Acho que a idéia pode até ser válida para algum caso específico (estrito).
Aplicar em tudo é puramente perda de performance.
Creio que o motivo pelo qual o warning não é disparado é justamente para o caso de você poder usar a função func_get_args().
Na minha opinião é desnecessário, é bacana validar entradas.
De onde você leu/tirou isso?
Eu posso perfeitamente fazer isso:
trigger_error() foi mais utilizada na versão 4 quando não havia ainda o suporte ao lançamento de exceções por isso o uso é maior em funções, talvez por isso você pense assim. Exceções são mais elegantes e mais fáceis de se manipular em relação ao trigger_error(). Então escolher qual utilizar fica a seu critério, eu prefiro lançar exceções.