1: Exception Handling Handling Errors during the Program Execution
2: Agenda What are Exceptions? Handling Exceptions The System. Exception Class Types of Exceptions and their Hierarchy Raising (Throwing) Exceptions Best Practices
3: What are Exceptions? The exceptions in . NET Framework are classic implementation of the OOP exception model Deliver powerful mechanism for centralized handling of errors and unusual events Substitute procedure-oriented approach, in which each function returns error code Simplify code construction and maintenance Allow the problematic situations to be processed at multiple levels
4: Handling Exceptions In C the exceptions can be handled by the try-catch-finally construction catch blocks can be used multiple times to process different exception types
5: Handling Exceptions – Example
6: The System. Exception Class Exception is a base class for all exceptions Important properties: Message – user-oriented message about error Source – name of an error source (application or object) InnerException – inner exception (if called from other) StackTrace – call stack to the point of exception call TargetSite – method name which raised an exception HelpLink – URL-address to information about exception Data – dictionary with additional information with exception (IDictionary)
7: Exception Properties – Example
8: Exception Properties The Message property gives brief description of the problem The StackTrace property is extremely useful when identifying the reason caused the exception
9: Exception Properties (2) File names and line numbers are accessible only if the compilation was in Debug mode When compiled in Release mode, the information in the property StackTrace is quite different:
10: Exception Hierarchy Exceptions in . NET Framework are organized in a hierarchy
11: Types of Exceptions . NET exceptions inherit from System. Exception The system exceptions inherit from System. SystemException, e. g. System. ArgumentException System. NullReferenceException System. OutOfMemoryException System. StackOverflowException User-defined exceptions should inherit from System. ApplicationException
12: Handling Exceptions When catching an exception of a particular class, all its inheritors (child exceptions) are caught too Example: Handles ArithmeticException and its descendants DivideByZeroException and OverflowException
13: Find the Mistake!
14: Handling All Exceptions All exceptions thrown by . NET managed code inherit the System. Exception exception Unmanaged code can throw other exceptions For handling all exceptions (even unmanaged) use the construction:
15: Throwing Exceptions Exceptions are thrown (raised) by throw keyword in C Used to notify the calling code in case of error or unusual situation When an exception is thrown: The program execution stops The exception travels over the stack until a suitable catch block is reached to handle it Unhandled exceptions display error message
16: How Exceptions Work?
17: Using throw Keyword Throwing an exception with an error message: Exceptions can accept message and cause: Note: if the original exception is not passed the initial cause of the exception is lost
18: Re-Throwing Exceptions Caught exceptions can be re-thrown again:
19: Throwing Exceptions – Example
20: Choosing the Exception Type When an invalid parameter is passed to a method: ArgumentException, ArgumentNullException, ArgumentOutOfRangeException When requested operation is not supported NotSupportedException When a method is still not implemented NotImplementedException If no suitable standard exception class is available Create own exception class (inherit Exception)
21: The try-finally Statement The statement: Ensures execution of given block in all cases When exception is raised or not in the try block Used for execution of cleaning-up code, e. g. releasing resources
22: try-finally – Example
23: Exceptions – Best Practices catch blocks should begin with the exceptions lowest in the hierarchy And continue with the more general exceptions Otherwise a compilation error will occur Each catch block should handle only these exceptions which it expects If a method is not competent to handle an exception, it should be left unhandled Handling all exceptions disregarding their type is popular bad practice (anti-pattern)!
24: Exceptions – Best Practices (2) When raising an exception always pass to the constructor good explanation message When throwing an exception always pass a good description of the problem Exception message should explain what causes the problem and how to solve it Good: "Size should be integer in range 1…15" Good: "Invalid state. First call Initialize()" Bad: "Unexpected error" Bad: "Invalid argument"
25: Exceptions – Best Practices (3) Exceptions can decrease the application performance Throw exceptions only in situations which are really exceptional and should be handled Do not throw exceptions in the normal program control flow (e. g. for invalid user input) CLR could throw exceptions at any time with no way to predict them E. g. System. OutOfMemoryException
26: Summary Exceptions provide flexible error handling mechanism in . NET Framework Allow errors to be handled at multiple levels Each exception handler processes only errors of particular type (and its child types) Other types of errors are processed by some other handlers later Unhandled exceptions cause error messages Try-finally ensures given code block is always executed (even when an exception is thrown)
27: Exceptions Handling