L’Exception
La première chose que je regarde lors de l'évaluation du code de quelqu'un est un bloc try / catch. Même s'il n'est pas un indicateur parfait, la gestion des exceptions est l'une des rares choses qui parlent vite sur la qualité du code. En quelques secondes, vous pourriez découvrir que l'auteur code n'a pas la moindre idée de ce qu'il ou elle fait. La gestion des exceptions pauvres peuvent avoir un impact sérieux sur la maintenance d'un système. Une bonne gestion des exceptions n'est pas très difficile, techniquement il n'y a rien à elle. Le tout se résume à saisir les fondements. Trop nombreux développeurs envisagé des exceptions dangereux pour le système.
Trois façon d’exceptions Catch en ASP.NET
1. Attraper Exceptions dans le Méthode(Fonction)
public void DownloadPdf(string path)
{
try
{
System.IO.StreamReader reader = System.IO.File.OpenText(path);
}
catch (System.UnauthorizedAccessException ex)
{
//Hey, vous n'avez pas accès à la file!
}
catch (System.IO.FileNotFoundException ex)
{
// Eh oui, le fichier n'existe pas
}
catch (Exception ex)
{
// Oh La..la...
}
}
2. Attraper Exceptions niveau du Page
protected override void OnError(EventArgs e)
{
Exception exception = HttpContext.Current.Server.GetLastError();
// Informer l'utilisateur sur l'exception, l'enregistrer dans le log..etc..
}
3. Attraper Exceptions au niveau d’application
// In global.asax
protected void Application_Error(object sender, EventArgs e)
{
Exception ex = HttpContext.Current.Server.GetLastError();
// Faites ce que, à l'exception ici.
}
Quelque Règle de bas :
Ne jetez pas new Exception ()
Exception est une classe trop large, et il est difficile d'attraper sans effets secondaires. Dériver votre propre classe d'exception, mais dériver celui-ci ApplicationException. De cette manière vous pouvez définir un gestionnaire d'exception spécialisés pour les exceptions levées par le « framework » et l'autre pour les exceptions levées par vous-même.
Ne mettez pas d'information importante exception sur le champ Message
Les exceptions sont des classes. Lorsque vous retourner les informations exception, créer des champs pour stocker des données. Si vous ne parvenez pas à faire ça, les gens vont avoir à analyser le champ Message d'obtenir l'information dont ils ont besoin. Maintenant, imaginez ce qui se passera au code appelant si vous avez besoin de localiser ou même à corriger juste une faute d'orthographe dans les messages d'erreur. Vous ne savez jamais mai code combien vous allez vous casser en le faisant.
Mettre « single catch » (Exception ex) par thread
La gestion des exceptions génériques devraient se faire en un point central dans votre application. Chaque thread a besoin d'un essai séparé / bloc catch, ou vous perdrez des exceptions et vous aurez des problèmes difficiles à comprendre. Quand une application se lance plusieurs threads de faire de traitement en arrière, souvent vous créez une classe pour le stockage des résultats du traitement. N'oubliez pas d'ajouter un champ pour le stockage d'une exception qui pourrait arriver ou vous ne serez pas en mesure de le communiquer au thread principal. Dans "fire and forget" des situations, vous n'aurez probablement besoin de dupliquer le gestionnaire principal exception handler au the thread handler.
Exceptions génériques capturés devraient être publiés
Il n'a vraiment pas d'importance ce que vous utilisez pour vous connecter - log4net, FEI, Event Log, TraceListeners, les fichiers texte, etc Ce qui est vraiment important, c'est: si vous avez attrapé une exception générique. Mais ce journal qu'une seule fois - souvent code est monté avec des blocs catch qui exceptions journal et vous vous retrouvez avec un journal grand, avec trop d'informations répétées d'être utile.
Ne prends pas (Exception) plus d'une fois par thread
Il existe de rares exceptions près (sans jeu de mots) à cette règle. Si vous avez besoin pour intercepter une exception, utilisez toujours l'exception la plus spécifique pour le code que vous écrivez.
Je vois toujours les débutants penser que bon code est un code qui ne lève pas d'exceptions. Ce n'est pas vrai. Bon code envoie des exceptions au besoin, et ne gère que les exceptions, il sait comment manier.
Conclusion
Vous ne devriez lancer des exceptions quand une condition en dehors des hypothèses de votre code produit. En d'autres termes, n'utilisez pas des exceptions comme un moyen de fournir la fonctionnalité de votre intention, même si quelque chose s'est mal passé.
Toutefois, une exception doit être généré si un véritable état de légitime inattendu se produit, comme une base de données utilisateur indisponible. Jeter ou de permettre des exceptions à jeter est plus cher que de simplement revenir suite à un appelant ou d'avoir le code pour gérer une condition attendue. Par conséquent, les exceptions ne devraient pas être utilisées pour contrôler le flux normal de l'exécution par le biais de votre code.