¿Es malo lanzar excepciones a los errores del servidor de retorno, por ej. ¿404 Pagina no encontrada?

Estoy trabajando en un framework PHP y actualmente estoy diseñando el manejo de errores. Basado en lo que he leído en SO, solo debería usar excepciones para, bueno, situaciones excepcionales. Por lo tanto, lanzar una excepción cuando se ingresa una contraseña incorrecta es incorrecta.¿Es malo lanzar excepciones a los errores del servidor de retorno, por ej. ¿404 Pagina no encontrada?

¿Debo evitar el uso de excepciones cuando deseo devolver un código de error del servidor al usuario (por ejemplo, 404 Página no encontrada)? Si es así, ¿debería escribir mi propia clase de manejo de errores?

Fuente

2010-05-07 Peter Horne

Tengo una pregunta de seguimiento para cualquiera que responda a esta pregunta: Supongamos que un usuario visita una página con 3 registros en ella. Hacen clic en un enlace para editar un registro en particular, pero entre el momento en que se emitió la página de la lista y la hora en que hacen clic en el registro, ese registro en particular fue eliminado de la base de datos. ¿Debe la página de edición arrojar una excepción cuando la función de recuperación de la base de datos devuelve NULL?Obviamente, el código que representa la vista manejaría tales excepciones y mostraría un mensaje de error apropiado, pero tengo curiosidad acerca de cómo se manejaría esa situación internamente. –

@RenderIn Si el controlador/vista pudiera establecer la respuesta a 404, y mostrar una página adecuada "que falta", diría que es el mejor lugar para manejarlo (ver mi respuesta). Dicho esto, cuando se está creando un prototipo de algo, es mucho más fácil simplemente lanzar la excepción sabiendo que el controlador de error al menos alertará al usuario de que la solicitud no fue exitosa. –

Su código no debe arrojar una excepción para interactuar con el usuario, debe arrojar la excepción para notificar a un nivel superior de código que algo irrecuperable sucedió.

Ahora, dependiendo de lo que sucedió, es posible que desee responder con un determinado código de estado HTTP. Pero en ese momento no está lanzando excepciones para desencadenar un error del servidor, está detectando excepciones y dando al usuario una respuesta adecuada.

Si las preguntas son qué debería suceder cuando se solicita un artículo/blog/elemento/etc. que no existe - bueno, si es posible que el código responsable de mostrar la información simplemente establezca el código de respuesta, entonces por supuesto, no use excepciones.

Si está utilizando un marco MVC, y sus controladores individuales pueden establecer el código de respuesta, déjelos.

Y si el controlador de excepción superior puede usar un código de respuesta http para presentar mejor el mensaje de error al usuario, entonces déjelo.

Fuente

2010-05-07 18:51:46

Agregué un poco de un ejemplo. Debo decir que en este momento me cuesta pensar en una situación en la que un código de respuesta sea útil en el gestor de excepciones de nivel superior de un marco MVC, suponiendo que pueda establecer el código de respuesta en los controladores. –

Las excepciones se deben limitar SÓLO a aquellos momentos en que la aplicación realmente no puede manejar la situación.

Como dijo, lanzar una excepción para una contraseña incorrecta es muy incorrecta.

Las únicas situaciones de tipo de error de servidor que puedo encontrar son si un recurso requerido (como su servidor sql) no estaba disponible.

Más allá de eso, acceso denegado, etc. son todas las ocurrencias comunes que su aplicación debe tener una forma normal de manejar.

Fuente

2010-05-07 17:57:08 NotMe

creo que está hablando de dos cosas diferentes:

errores que se produce cuando algo ha ido mal en el propio marco o el marco se utiliza de una manera que no debería funcionar.
Códigos de estado HTTP (la página 404 no encontrada mencionada en el tema es código de estado).

En las primeras situaciones, lanzar una excepción es la forma correcta de hacerlo, si quiere resolver el problema utilizando un enfoque orientado a objetos. Los códigos de estado HTTP son parte del protocolo HTTP y su estructura no debería manejarlos de ninguna manera.

Fuente

2010-05-07 18:03:26 pkainulainen

OOP no tiene nada que ver con arrojar excepciones (Marco o no). Lo único que importa es si se trata de una situación que puede tratarse o no. Si la situación es tan grave que la aplicación básicamente debe vomitar, entonces sí, una buena excepción con detalles sobre el problema es buena. Sin embargo, si es algo que puede evitar diciéndole al usuario que no puede hacer eso, pidiendo más información o tomando una ruta diferente con el comando, entonces no use una excepción ya que el problema es bastante corriente. – NotMe

"Los códigos de estado HTTP son parte del protocolo HTTP y su marco no debería manejarlos de ninguna manera". Hay una serie de situaciones en las que me gustaría devolver un 404 si no hay información contenida en mis modelos, seguramente la única forma de hacerlo es activar un error 404 en mi código. –

Solo por curiosidad, ¿cuántos lenguajes que no usan OOP realmente son compatibles con tirar excepciones? He estado acostumbrado a ver que se usan códigos de retorno en lugar de arrojar excepciones. Entonces, debido a esto, he pensado que los lenguajes de programación que siguen algún otro paradigma que OOP no los admiten. Quizás estoy equivocado entonces. – pkainulainen

Las excepciones no son mecanismos de control de flujo.

Fuente

2010-05-07 18:37:17 Adrian

Esa es una declaración audaz. ¿Podrías por favor elaborar? – itsafire

¿Es malo lanzar excepciones a los errores del servidor de retorno, por ej. ¿404 Pagina no encontrada?

Respuesta

Cuestiones relacionadas