sistematizando los códigos de error para una aplicación web en php?

Question

Estoy trabajando en una aplicación web php basada en clase. Tengo algunos lugares en los que los objetos interactúan, y tengo ciertas situaciones en las que utilizo códigos de error para comunicarme con el usuario final, generalmente cuando los valores de los formularios faltan o no son válidos. Estas son situaciones en las que las excepciones no están justificadas (y no estoy seguro de poder evitar las situaciones con excepciones).

En un objeto, tengo unos 20 números de código, cada uno de los cuales corresponde a un mensaje de usuario, y un mensaje de administrador/orientador, por lo que ambas partes saben lo que está sucediendo. Ahora que he trabajado varias veces en el código, me resulta difícil averiguar rápidamente qué números de código de la serie ya he utilizado, así que accidentalmente creo números de código conflictivos. Por ejemplo, acabo de hacerlo hoy con 12, 13, 14 y 15.

¿Cómo puedo organizar mejor esto para que no cree códigos de error conflictivos? ¿Debería crear una clase singleton, errorCodes, que tenga una lista maestra de todos los códigos de error para todas las clases, sistematizándolos en toda la aplicación web? ¿O debería cada objeto tener su propio conjunto de códigos de error, cuando corresponda, y solo tengo una lista en el comentario del objeto, para usar y actualizar eso a medida que avanzo?

---

Editar: Así que me gustan las sugerencias para usar constantes o constantes con nombre dentro de la clase. Eso me da un lugar único donde defino programáticamente y hago un seguimiento de los códigos de error y sus mensajes.

La siguiente pregunta: ¿qué tipo de interfaz proporciono al mundo exterior para los códigos y mensajes de error de esta clase? ¿Hago algo como triggerError(20) en la clase, y luego proporciono un método público para devolver el código de error, la constante de cadena y el mensaje de usuario y administrador?

Answer 1

Se puede crear un par de defines para crear constantes con nombre para todos sus códigos de error:

define('ERROR_CODE_SQL_QUERY', 1); 
define('ERROR_CODE_PAGE_NOT_FOUND', 2); 
define('ERROR_CODE_NOT_ALLOWED', 3); 
// and so on 

Y, a continuación, utilizar las constantes en el código:

if ($errorCode == ERROR_CODE_SQL_QUERY) { 
    // deal with SQL errors 
} 

Con eso, en ningún lugar de tu código usarás el valor numérico: en todas partes (excepto en el único archivo donde pones el define s), usará los códigos.

Significa:

• Menos riesgo de errores, ya que todos los valores numéricos se fijan en un solo archivo
• Menos riesgo de errores, ya que vamos a usar las constantes, que tienen un nombre que indica lo que significa
• Y el código es más fácil de leer.

Otra idea podría ser la creación de una clase para hacer frente a los errores:

class Error { 
    const CODE_SQL_QUERY = 1; 
    const CODE_PAGE_NOT_FOUND = 2; 
    const CODE_NOT_ALLOWED = 3; 

    // Add some methods here, if needed 
} 

Y, a continuación, utilizar algo como esto:

if ($errorCode == Error::CODE_SQL_QUERY) { 
    // deal with SQL errors 
} 

Cuál es el mejor?

Probablemente es una cuestión de preferencias personales ... Si necesita agregar algunos métodos para manejar los errores, usar una clase podría ser útil. De lo contrario, define son una gran solución también.

Answer 2

Por lo menos, ¿puede encontrar los números de código para ser constantes de clase o miembros?

class MyErrorProneClass { 
    const TURNED_INTO_A_NEWT = 12; 
    ... 

    public function dontBurnMe() { 
     // echo your error here using self::TURNED_INTO_A_NEWT 
} 

De esta manera se pueden gestionar los errores en el mismo lugar donde se los utiliza, en lugar de tener que el mantenimiento de un archivo grande central. Intenté algo así en el pasado y es difícil mantener el ritmo.

Generar números de error mediante programación puede ser una mejor solución a largo plazo. Si pudiera usar información sobre el archivo o número de línea (__FILE__ y __LINE__ respectivamente), eso ayudaría.

Espero que se mueva en la dirección correcta al menos.

Gracias, Joe

---

Editar:

Un miembro de la clase seguiría esta sintaxis en su lugar:

class MyErrorProneClass { 
    protected static $turnedIntoANewt = 12; 
    ... 

    public function dontBurnMe() { 
     // echo your error here using self::$turnedIntoANewt 
} 

Dado que las constantes son públicos por defecto, se puede acceder a ellos desde otras clases directamente si quieres Así, desde el exterior, se hace referencia al error como:

MyErrorProneClass::TURNED_INTO_A_NEWT 

para asociar a los mensajes, se utilizaría un mapeo (ya sea en una base de datos, o en algún archivo de localización) de ID de error (y frontend/backend) a la cadena mostrada. Este uso de claves para mensajes no es óptimo, pero también le permite cambiar los mensajes de error sin cambiar el código.

Answer 3

Si no sabe ya, puede ser una idea utilizar trigger_error(), más un controlador de errores si desea presentar al usuario un mensaje de error mejor.

Answer 4

¿Has pensado en usar exceptions? Pueden ser una buena opción para su problema aquí, aunque agregarlos a su proyecto ahora probablemente requeriría alguna reestructuración.

Puede ampliar la clase de excepción básica para que se adapte a su problema en términos de la separación de mensajes de error del usuario/desarrollador.