Para uma aplicação web, os erros são inevitáveis, por isso devemos tomar precauções e fornecer o tratamento adequado para possíveis erros. Na verdade, um bom mecanismo de tratamento de erros é um critério importante para medir a qualidade das aplicações web. Imagine só, quando o usuário insere acidentalmente a URL errada no navegador ou quando o usuário fornece alguma informação que causa erro no programa, se não cuidarmos dessas situações, permitimos 404 ou 500 páginas de erro ou até mesmo erros na pilha de informações. é apresentado aos usuários, o que sem dúvida assustará alguns usuários. Portanto, quando desenvolvemos aplicações web, devemos ter um entendimento completo do mecanismo de tratamento de erros.
Vamos voltar ao ASP.NET e fazer duas perguntas para que todos pensem: Quantos mecanismos de tratamento de erros o ASP.NET nos fornece? Se vários mecanismos de tratamento de erros forem usados ao mesmo tempo, existe uma certa prioridade entre eles? Com esta questão em mente, vamos primeiro dar uma olhada em nosso arquivo Web.Config mais comum:
<?xml version="1.0"?>
<configuração>
<sistema.web>
<customErrors mode="Ativado" defaultRedirect="GenericErrorPage.htm">
<error statusCode="403" redirecionamento="Error403.htm" />
<error statusCode="404" redirecionamento="Error404.htm" />
</customErrors>
</system.web>
</configuração>
Em relação ao item de configuração <customErrors>, acho que não há necessidade de dizer mais detalhes, consulte o MSDN. O primeiro mecanismo de tratamento de erros - usando o item de configuração <customErrors> do Web.Config deve ser o mais comumente usado.
A seguir, vejamos outro arquivo que também é muito usado: Global.asax. Quando você menciona este documento, o que você pensa? Sim, são eventos relacionados aos dois principais objetos da aplicação Web (Aplicativo e Sessão). Dentre esses eventos, existe um evento relacionado a erros que pertence à categoria Aplicativo - Erro, e o método de processamento de eventos correspondente é Application_Error. Como o nome sugere, este método de tratamento de eventos será chamado quando ocorrer um erro no nível do aplicativo, então você pode adicionar código neste método para tratar o erro, conforme mostrado abaixo:
protected void Application_Error(object sender, EventArgs e) {
Exceção objErr = Server.GetLastError().GetBaseException();
Response.Write("Erro:" + objErr.Message);
Servidor.ClearError();
}
Aqui, todos devem prestar atenção ao uso de Server.ClearError() na última linha do código. Por que esta linha de código deve ser usada? O que acontece se você não usar? Aqui vou tentar novamente. Bem, o segundo mecanismo de tratamento de erros - usando o método de tratamento de eventos Application_Error em Global.asax também fez sua estreia.
Os dois métodos de tratamento de erros acima podem ser considerados globais. Um é derivado do arquivo de configuração do aplicativo e o outro é o método de tratamento de eventos do arquivo Global.asax que deve ser colocado no diretório raiz do aplicativo. O oposto do global é o local, então naturalmente nos perguntamos: existe um mecanismo de tratamento de erros que se aplica ao local – uma determinada página? A resposta é "sim" e há duas maneiras - usando o atributo ErrorPage e usando o método de manipulação de eventos Page_Error. Para o primeiro mecanismo, você pode definir a propriedade ErrorPage quase a qualquer momento para determinar para qual página será redirecionada quando ocorrer um erro na página. Para o segundo mecanismo, é muito semelhante ao método de manipulação de eventos Application_Error, exceto que Mas; o momento de ser acionado é diferente. A seguir estão dois exemplos específicos:
<script language="C#" runat="server">
protegido void Page_Load(objeto remetente, EventArgs e) {
this.ErrorPage = "ErrorPage.htm";
}
</script>
protegido void Page_Error(objeto remetente, EventArgs e) {
Exceção objErr = Server.GetLastError().GetBaseException();
Response.Write("Erro:" + objErr.Message);
Server.ClearError(); //Preste atenção também ao uso deste código
}
Neste ponto, todos os quatro mecanismos de tratamento de erros apareceram e é hora de classificá-los. Classifique de alta prioridade para baixa: método de manipulação de eventos Page_Error > propriedade ErrorPage > método de manipulação de eventos Application_Error > item de configuração <customErrors>. Embora a classificação seja assim, há uma relação sutil entre as classificações. Em primeiro lugar, para que o atributo ErrorPage funcione, o atributo mode no item de configuração <customErrors> deve ser definido como "On"; em segundo lugar, embora o método de processamento de eventos Page_Error seja classificado em primeiro lugar, se o método Server.ClearError() for; ausente Nesse caso, o tratamento de erros de prioridade mais baixa ainda será acionado. Isso também se aplica ao método de tratamento de eventos Application_Error. A ordem está arranjada, mas a ordem não é a questão mais importante. Pode-se até dizer que é uma questão que não tem muito significado, porque em muitos casos não é possível misturar esses quatro mecanismos de processamento. Acho que a questão mais importante é como escolher esses mecanismos de tratamento de erros. Em relação a este assunto, espero que amigos experientes possam compartilhar suas opiniões.
Ok, é isso para apresentar os quatro mecanismos de tratamento de erros do ASP.NET, e é hora de falar sobre alguns dos meus próprios sentimentos. Os projetistas do ASP.NET realmente fizeram considerações minuciosas da perspectiva dos desenvolvedores, portanto, eles fornecem até quatro mecanismos de tratamento de erros para escolhermos, o que é louvável. Mas parafraseando um slogan publicitário - demasiado é confuso, também ficaremos um pouco tontos com tantos mecanismos de tratamento de erros. Comparando o tratamento de erros no campo J2EE, podemos descobrir que é relativamente simples. A primeira é a configuração correspondente a <customErrors>. Também podemos encontrar itens de configuração semelhantes no arquivo web.xml mais comumente usado em projetos J2EE: <errorPage>; evento O modelo do driver não é necessário, então realmente não consigo encontrar o mecanismo de processamento correspondente para os métodos Application_Error e Page_Error. Finalmente, no campo do J2EE, mais ênfase é colocada em Solicitação e Resposta. , Podemos distribuir facilmente a solicitação para o módulo de tratamento de erros correspondente por meio do RequestDispatcher. Na verdade, este é um método de processamento muito flexível. Amigos interessados podem querer aprender sobre ele.