switch - registrar datos en mysql con php

¿Por qué y cómo usarías Excepciones en este código PHP de muestra?

Question

Me he estado preguntando por qué usaría Excepciones en mi PHP. Echemos un vistazo a un ejemplo simple:

class Worker
{
 public function goToWork()
 {
  return $isInThatMood ?
  // Okay, I''ll do it.
  true : 
  // In your dreams...
  false;
 }
}

$worker = new Worker;
if (!$worker->goToWork())
{
 if (date(''l'',time()) == ''Sunday'')
  echo "Fine, you don''t have to work on Sundays...";
 else
  echo "Get your a** back to work!";
}
else
 echo "Good.";

¿Hay alguna razón para que use Excepciones para ese tipo de código? ¿Por qué? ¿Cómo se construiría el código?

Y ¿qué pasa con el código que puede producir errores?

class FileOutputter
{
 public function outputFile($file)
 {
  if (!file_exists($file))
   return false;
  return file_get_contents($file);
 }
}

¿Por qué debería usar Excepciones en el caso anterior? Tengo la sensación de que las Excepciones te ayudan a reconocer el tipo de problema que ocurrió, ¿cierto?

Entonces, ¿estoy usando Excepciones apropiadamente en este código?

class FileOutputter
{
 public function outputFile($file)
 {
  if (!file_exists($file))
   return throw new Exception("File not found.",123);
  try
  {
   $contents = file_get_contents($file);
  }
  catch (Exception $e)
  {
   return $e;
  }
  return $contents;
 }
}

¿O es eso pobre? Ahora el código subyacente puede hacer esto:

$fo = new FileOutputter;
try
{
 $fo->outputFile("File.extension");
}
catch (Exception $e)
{
 // Something happened, we could either display the error/problem directly
 echo $e->getMessage();
 // Or use the info to make alternative execution flows
 if ($e->getCode() == 123) // The one we specified earlier
  // Do something else now, create "an exception"
}

¿O estoy completamente perdido aquí?

Answer 1

¿Cuándo debería usar una excepción?

Utiliza una excepción para indicar una condición excepcional ; es decir, algo que impide que un método cumpla su contrato, y que no debería haber ocurrido en ese nivel.

Por ejemplo, puede tener un método, Record::save() , que guarda los cambios en un registro en una base de datos. Si, por alguna razón, esto no se puede hacer (p. Ej., Se produce un error en la base de datos o se rompe una restricción de datos), puede lanzar una excepción para indicar la falla.

¿Cómo creo excepciones personalizadas?

Las excepciones se suelen nombrar de manera que indiquen la naturaleza del error, por ejemplo, DatabaseException . Puede subclase Exception para crear Exception personalizadas de esta manera, por ejemplo

class DatabaseException extends Exception {}

(Por supuesto, puede aprovechar la herencia para dar a esta excepción información de diagnóstico adicional, como detalles de conexión o un código de error de base de datos, por ejemplo).

¿Cuándo no debería usar una excepción?

Considera otro ejemplo; un método que verifica la existencia de archivos. Esto probablemente no debería arrojar una excepción si el archivo no existe, ya que el propósito del método era realizar dicha verificación. Sin embargo, un método que abre un archivo y realiza algún procesamiento podría lanzar una excepción, ya que se esperaba que existiera el archivo, etc.

Inicialmente, no siempre está claro cuando algo es y no es excepcional. Como la mayoría de las cosas, la experiencia le enseñará, con el tiempo, cuándo debería y no debería lanzar una excepción.

¿Por qué usar excepciones en lugar de devolver códigos de error especiales, etc.?

Lo útil de las excepciones es que saltan de inmediato del método actual y suben la pila de llamadas hasta que son capturadas y manejadas, lo que significa que puedes mover la lógica de manejo de errores más arriba, aunque idealmente, no demasiado alto.

Al usar un mecanismo claro para tratar casos de falla, automáticamente se inicia el código de manejo de errores cuando ocurre algo malo, lo que significa que puede evitar el manejo de todo tipo de valores centinela mágicos que deben verificarse, o peor, una bandera de error global para distinguir entre un montón de diferentes posibilidades.

Answer 2

No soy un programador de PHP, pero esto se parece a C #.

Por lo general, querría lanzar errores si es un punto de no retorno. Entonces, podrías registrar algo para demostrar que sucedió lo imposible.

Si puede ver que el archivo no existe, entonces podría decir eso. No es realmente necesario en mi mente lanzar una excepción.

Ahora bien, si se encontró el archivo y lo está procesando, y dice que solo se cargó la mitad del archivo y que no tenía manera de decirlo sin excepción, sería agradable tenerlo cerca.

Diría que es una buena práctica de diseño evitar las excepciones de catch catch (Exception $ e) y diseñar por contrato, al igual que parece estar haciendo en el ejemplo anterior. Al principio sería más específico con el tipo de excepción lanzada y luego trabajaré desde allí si fuera necesario. De lo contrario, manténgase alejado del try-> catch y las excepciones.

Answer 3

Solo una nota, su código para el archivo de salida no es válido, ya que file_get_contents ($ file) no lanza una excepción. Sin embargo, generará una advertencia si el archivo no existe o no se puede acceder por alguna razón. Además, está devolviendo una excepción de outputFile, cuando probablemente debería dejar que el error se propague por la pila de llamadas.

Sin embargo, puede registrar el controlador de errores en php para lanzar excepciones cuando se produce un error:

function exception_error_handler($errno, $errstr, $errfile, $errline ) {
    throw new ErrorException($errstr, 0, $errno, $errfile, $errline);
}
set_error_handler("exception_error_handler");

De esta forma, cualquier función estándar llamada que cause un error generará una excepción.

Entonces, cambiaría FileOutputter a esto (con ese fragmento agregado arriba):

class FileOutputter
{
 public function outputFile($file)
 {
  if (!file_exists($file))
   throw new Exception("File not found.",123);

   return file_get_contents($file);  
 }
}

El código de llamada es básicamente el mismo.

Básicamente, la regla es no devolver una excepción cuando se produce un error: puede atraparlo si lo desea y lanzar una excepción personalizada, pero permita que la excepción suba en la pila de llamadas hasta que quiera usarla.

Answer 4

¡De ninguna manera puede suponer que un archivo existe simplemente porque llamó a file_exists() ! La función file_exists no abre el archivo, por lo que el archivo se puede eliminar, cambiar de nombre o mover en cualquier momento.

class FileOutputter
{
    public function outputFile($file)
    {
        if (!file_exists($file))
            return false;
        ///<--- file may be deleted right here without you knowing it
        return file_get_contents($file);//<-- then this will throw an error
            //if you don''t catch it, you''re program may halt.
    }
}

Yo creo que esto es mejor:

class FileOutputter
{
    public function outputFile($file)
    {
        try{
            if (!file_exists($file))
                return false;
            return file_get_contents($file);
        }catch(Exception e){
            check_what_went_wrong_and_go_to_plan_B();
        }
    }
}

( Editar : Y probablemente sea mejor incluso tratar de abrir el archivo desde el principio. Si tiene éxito, entonces tiene un ''bloqueo'' en el archivo y no solo desaparecerá. De lo contrario, atrape la excepción y vea qué salió mal.

Por otra parte, puede sentir que este nivel de reduncionamiento es simplemente tonto. En ese caso, no creo que deba preocuparse por try/catch en absoluto :)