Εξαίρεση χειρισμού είναι η τεχνική χειρισμού σφαλμάτων χρόνου εκτέλεσης στον κωδικό της εφαρμογής σας. Βασικά, έχετε δύο κατηγορίες εξαιρέσεων: Εξαιρέσεις που δημιουργούνται από την εφαρμογή και εκείνες που δημιουργούνται από τον χρόνο εκτέλεσης. Οι εξαιρέσεις πρέπει να αντιμετωπίζονται με προσοχή - θα πρέπει να έχετε μια καλή ιδέα για το πώς πρέπει να χειρίζονται τις εξαιρέσεις και πότε πρέπει να αντιμετωπιστούν στον κώδικά σας. Σε αυτήν την ανάρτηση, θα παρουσιάσω μερικές συμβουλές και βέλτιστες πρακτικές για εργασία με εξαιρέσεις στο C #.
Η βασική κλάση για όλες τις εξαιρέσεις στο .NET είναι Εξαίρεση. Όλες οι τάξεις εξαίρεσης στην ιεραρχία εξαιρέσεων προέρχονται άμεσα ή έμμεσα από αυτήν την τάξη. Οι κλάσεις ApplicationException και SystemException προέρχονται από την κατηγορία Exception. Το Common Language Runtime (CLR) ρίχνει μια παρουσία ενός τύπου που προέρχεται από το SystemException όταν παρουσιάζεται σφάλμα κατά το χρόνο εκτέλεσης. Σημειώστε ότι δεν πρέπει ποτέ να πιάσετε το SystemException ή να ρίξετε μια παρουσία του SystemException στον κώδικα της εφαρμογής σας.
Κατά τη δημιουργία προσαρμοσμένων κλάσεων εξαίρεσης, προέρχεστε πάντα από την κατηγορία Εξαίρεσης και όχι από την κλάση ApplicationException. Ένας από τους λόγους για αυτό είναι ότι μια παρουσία του ApplicationException ρίχνεται από την εφαρμογή και ποτέ από το χρόνο εκτέλεσης. Όταν ρίχνετε μια παρουσία του ApplicationException στον κώδικά σας, θα αυξήσετε απλώς τη στοίβα κλήσεων χωρίς να προσθέσετε μεγάλη αξία.
Είναι μια κακή προσέγγιση σχεδιασμού για να χρησιμοποιήσετε χειρισμό εξαιρέσεων για την επιστροφή πληροφοριών από μια μέθοδο. Εάν επιστρέφετε δεδομένα εξαιρέσεων από τη μέθοδο σας, ο σχεδιασμός της τάξης σας είναι λανθασμένος και πρέπει να επανεξεταστεί. Λάβετε υπόψη ότι οι εξαιρέσεις διοχετεύονται στο υψηλότερο επίπεδο στην ιεραρχία κλήσεων μεθόδου και δεν είναι καλή πρακτική να χειρίζεστε εξαιρέσεις σε όλα τα επίπεδα της εφαρμογής σας. Θα πρέπει να χειριστείτε μια εξαίρεση όσο πιο ψηλά γίνεται στην ιεραρχία κλήσεων - μπορείτε να χρησιμοποιήσετε μια εξαίρεση στο επίπεδο παρουσίασης και να εμφανίσετε κατάλληλα μηνύματα στον χρήστη για να ειδοποιήσετε το ακριβές σφάλμα που προέκυψε.
Απαιτείται εκ νέου εξαίρεση όταν θέλετε να κάνετε επαναφορά μιας συναλλαγής βάσης δεδομένων. Είναι καλή πρακτική να χρησιμοποιείτε συγκεκριμένες εξαιρέσεις όπως το FileNotFoundException, το IOException κ.λπ. κατά τη σύνταξη χειριστών εξαιρέσεων και στη συνέχεια ένα γενικό μπλοκ catch στο τέλος με την κατηγορία Exception. Αυτό θα διασφαλίσει ότι θα γνωρίσετε το ακριβές σφάλμα ή το συγκεκριμένο σφάλμα που προέκυψε. Το MSDN δηλώνει: "Η κλάση ApplicationException δεν παρέχει πληροφορίες σχετικά με την αιτία των εξαιρέσεων. Στα περισσότερα σενάρια, δεν πρέπει να δημιουργούνται περιπτώσεις αυτής της κλάσης. Σε περιπτώσεις όπου αυτή η τάξη έχει δημιουργηθεί, ένα μήνυμα αναγνώσιμο από τον άνθρωπο που περιγράφει το σφάλμα πρέπει να είναι πέρασε στον κατασκευαστή. "
Πρέπει να χρησιμοποιήσετε μπλοκ try-catch για να χειριστείτε τις εξαιρέσεις και να χρησιμοποιήσετε τελικά ένα μπλοκ για να καθαρίσετε τους πόρους που χρησιμοποιούνται στο πρόγραμμά σας. Το μπλοκ δοκιμής θα περιέχει κώδικα που θα μπορούσε να δημιουργήσει μια εξαίρεση, το μπλοκ αλιευμάτων θα χρησιμοποιηθεί για να χειριστεί την εξαίρεση που ρίχνεται μέσα στο μπλοκ δοκιμής και το μπλοκ τέλος θα χρησιμοποιηθεί για την αφαίρεση τυχόν πόρων που έχει χρησιμοποιήσει το πρόγραμμα. Σημειώστε ότι το τελευταίο μπλοκ είναι εγγυημένο ότι θα εκτελεστεί ανεξάρτητα από το αν έχει γίνει εξαίρεση ή όχι. Επομένως, το μπλοκ επιτέλους είναι το καλύτερο μέρος στον κώδικά σας για τον καθαρισμό των πόρων που έχει χρησιμοποιήσει το πρόγραμμά σας.
Το παρακάτω απόσπασμα κώδικα δείχνει πώς μπορεί να χρησιμοποιηθεί η δήλωση "using" για τη διάθεση πόρων. Σημειώστε ότι η δήλωση "using" είναι ισοδύναμη της δοκιμής - τελικά μπλοκ.
δημόσια συμβολοσειρά ανάγνωσης (string fileName)
{
δοκιμάστε
{
δεδομένα συμβολοσειράς;
χρησιμοποιώντας (StreamReader streamReader = νέο StreamReader (όνομα αρχείου))
{
data = streamReader.ReadToEnd ();
}
δεδομένα επιστροφής;
}
αλίευση (εξαίρεση)
{
βολή;
}
}
Η εξαίρεση είναι ακριβή. Είναι μια κακή πρακτική να επαναπροσδιορίζετε τις εξαιρέσεις - σε αναδρομικές εξαιρέσεις θα χάσετε το ίχνος στοίβας.
δοκιμάστε
{
// Κάποιος κώδικας που μπορεί να ρίξει μια εξαίρεση
}
αλίευση (πρώην εξαίρεση)
{
ρίξτε πρώην;
}
Αντ 'αυτού, απλώς χρησιμοποιήστε τη δήλωση "ρίξτε" εάν δεν θέλετε να χειριστείτε την εξαίρεση στον χειριστή εξαιρέσεων και μεταδώστε την εξαίρεση προς τα πάνω στην ιεραρχία κλήσεων.
δοκιμάστε
{
// Κάποιος κώδικας που μπορεί να ρίξει μια εξαίρεση
}
αλίευση (πρώην εξαίρεση)
{
βολή;
}
Μην καταπιείτε ποτέ εξαιρέσεις - δεν πρέπει ποτέ να αποκρύψετε το σφάλμα που έχει συμβεί. Είναι καλή πρακτική να καταγράφετε εξαιρέσεις στην εφαρμογή σας. Κατά την καταγραφή εξαιρέσεων, πρέπει πάντα να καταγράφετε την παρουσία εξαίρεσης έτσι ώστε να καταγράφεται ολόκληρο το ίχνος στοίβας και όχι μόνο το μήνυμα εξαίρεσης. Εδώ είναι ένα παράδειγμα που το απεικονίζει αυτό.
δοκιμάστε
{
// Κάποιος κώδικας που μπορεί να ρίξει μια εξαίρεση
}
αλίευση (πρώην εξαίρεση)
{
LogManager.Log (ex.ToString ());
}
Δεν πρέπει ποτέ να χρησιμοποιείτε εξαιρέσεις για τη διάδοση ή την εκτέλεση επιχειρηματικών κανόνων στην εφαρμογή σας. Μπορείτε να αποφύγετε εξαιρέσεις στον κώδικά σας χρησιμοποιώντας τη σωστή λογική επικύρωσης. Στις περισσότερες περιπτώσεις πρέπει να αποφεύγονται εξαιρέσεις - θα πρέπει να τις χρησιμοποιείτε μόνο όταν χρειάζεται.
Μπορείτε να ανατρέξετε σε αυτό το άρθρο MSDN για περισσότερες πληροφορίες.
