2010-06-10 19 views
5

Estoy buscando volver a trabajar y simplificar nuestro manejo de errores en una aplicación que admita. Actualmente tenemos todas nuestras páginas heredadas de una clase base que creamos, que a su vez obviamente hereda de System.Web.UI.Page. Dentro de esta clase base, el método OnError se está anulando actualmente y, a su vez, llamando a MyBase.OnError y luego llamando a uno de nuestros métodos de registro personalizados.Cuándo anular OnError?

No veo ningún beneficio de anular el método OnError, y creo que sería mejor dejar que el método Application_Error en Global.asax se ocupe de la excepción no controlada (iniciar sesión) y luego la sección customErrors en la configuración desencadenaría un proceso para redirigir al usuario.

Buscando en línea parece que las personas anulan este método con bastante frecuencia, pero no veo la necesidad de hacerlo y el artículo this de MSDN me hace pensar lo mismo.

Respuesta

2

que crear una clase personalizada llamada PageBase:

public class PageBase : Page 
{ 
    protected override void OnError(..) 
    { 
    //handle error, redirect to error page 
    } 
} 

Y por lo que sólo tiene que hacerlo una vez, y usarlo para atrapar errores no controlada y redirigir a la página de error. De esta manera tengo que hacerlo una vez; No sé si el evento Page.Error tiene pros o contras sobre el error de la aplicación; pero utilizo el error de página, ya que puede ser conveniente aquí; Puedo borrar el error y redireccionar a la página de error dentro del contexto de la página ... mi preferencia personal.

Gracias por el enlace de MSDN; ese fue un recurso bastante bueno.

HTH.

+0

Pero, de nuevo, ¿por qué reemplazar el método OnError? Si necesita manejar información dentro del contexto de la página, entiendo por qué desea manejar el error dentro de ese contexto (registrando datos específicos sobre la página, la entrada del usuario, muestra mensajes en la pantalla, etc.), pero ¿por qué anular? el método OnError existente en lugar de usar Page_Error o Application_Error? –

+0

page_error se origina en onerror (se llama a Page_Load desde el método OnLoad, etc.), por eso OnError; es lo mismo que Page_Error ... Así que la verdadera pregunta es por qué error de página vs. aplicación ... –

+1

Con el enlace que proporcioné arriba, el párrafo sobre la sección "global.asax: Application_Error" menciona que poner código en una El método OnError Override no es lo mismo que usar Page_Error. Por lo tanto, en su caso, supongo que está anulando esa funcionalidad para redirigir por su cuenta, por lo que probablemente esté bien. En mi caso, no estamos anulando ninguna de esas funciones dentro del método OnError, solo estamos haciendo un registro muy general sobre la excepción que se lanzó. Creo que podríamos poner el registro en el nivel de la aplicación y eliminar nuestro método OnError. Gracias por tu contribución. –

0

Pude ver un escenario donde tal vez solo algunas páginas de la aplicación heredan de la clase base y necesitan manejar los errores de forma diferente. Todos los demás errores serían capturados/registrados por Application_Error

2

Nunca he anulado el método OnError. Me gusta usar Application_Error del asax global, que a su vez atrapará las páginas que podrían no heredar de su clase base. Además, la anulación de un método se utiliza para cambiar su funcionalidad, por lo que si no lo hace, no lo anularía.

Además, sé que no es parte de su pregunta, pero me gustaría ver ELMAH para el registro de errores:

http://code.google.com/p/elmah/