Exceptions

1. Exceptions Error Handling in .NET

2. Error Handling • Old way (Win32 API and COM): MyFunction() { error_1 = doSomething(); if (error_1) display error else { continue processing if (error_2) display error else continue processing } }

3. How is Error Handled in .NET? • It uses Exceptions • Exception handling enables programmers to removeerror-handling code from the “main line” of the program’s execution. • Examples: • Without exceptions: DivideByZeroNoExceptionHandling.cs • With exceptions: DivideByZeroTest.sln

4. Syntax try { // code that requires common cleanup or // exception-recovery operations } catch (InvalidOperationException) { //code that recovers from an InvalidOperationException // (or any exception type derived from it) } catch (SomeOtherException) { // code that recovers from an SomeOtherException // (or any exception type derived from it) } catch { // code that recovers from any kind of exception // when you catch any exception, you usually re-throw throw; } finally { // code that cleans up any operations started // within the try block. This code ALWAYS executes. }

5. try block • A try block contains code that requires common cleanup or exception-recovery operations. • The cleanup code should be put in a single finally block. • The exception recovery code should be put in one or morecatch blocks. • Create one catch block for each kind of type you want to handle. • A try block must have at least one catch or finally block.

6. catch block • A catch block contains code to execute in response to an exception. • If the code in a try block doesn’t cause an exception to be thrown, the CLR will never execute the code in any of its catch blocks. • You may or may not specify a catch type in parantheses after catch : • The catch type must be of type System.Exception or a type that derived from System.Exception • If there is no catch type specified, that catch block handles any exception. This is equivalent to having a catch block that specifies System.Exception as a catch type. • CLR searches for a matching catch type from top to bottom. • If CLR cannot find any catch type that matches the exception, CLR continues searching up the callstack to find a catch type.

7. catch block • Once the catch block that matches the exception is found, you have 3 choices: • Re-throw the same exception, notifying the higher-up call stack of the exception • Throw a different exception, giving richer exception information to code higher-up in the call stack • Let the code continue from the bottom of the catch block • In choices 1-2, an exception is thrown and code starts looking for a catch block whose type matches the exception thrown • In choice 3, the finally block is executed • You can also specify a variable name like catch(Exception e) to access information specific to the exception.

8. finally block • The CLR does not completely eliminate memory leaks. Why? • Even though GC does automatic memory clean-up, it only cleans up if there are no references kept on the object. • Even then there may be a delay until the memory is required. • Thus, memory leaks can occur if programmers inadvertently keep references to unwanted objects. • C# provides the finally block, which is guaranteed to execute regardless of whether an exception occurs. • If the try block executes without throwing, the finally block executes. • If the try block throws an exception, the finally block still executes regardless of whether the exception is caught. • This makes the finally block ideal to release resources from the corresponding tryblock. • Example: UsingExceptions.cs

9. finally block • Local variables in a try block cannot be accessed in the corresponding finally block, so variables that must be accessed in both should be declared before the try block. • Placing the finallyblock before a catch block is a syntax error. • A try block does not require a finallyblock, sometimes no clean-up is needed. • A try block can have no more than one finallyblock. • Avoid putting code that might throw in a finallyblock. • Exception handling will still work but the CLR will not keep the information about the first exception just thrown in the corresponding try block.

10. using • The using statement simplifies writing code in which you obtain a resource. • The general form of a using statement is: using ( ExampleObject e = new ExampleObject() ) {e.SomeMethod(); } • This using statement code is equivalent to: {ExampleObject e = newExampleObject(); try{e.SomeMethod(); } finally{if ( e != null ) ( ( IDisposable ) e ).Dispose(); } }

11. System.Exception • In .NET, only objects of class Exception and its derived classes may be thrown and caught. • Exceptions thrown in other .NET languages can be caught with the general catch clause. • Class Exception is the base class of .NET’s exception class hierarchy. • A catch block can use a base-class type to catch a hierarchy of related exceptions. • A catch block that specifies a parameter of type Exception can catch all exceptions.

12. System.Exception Properties • Class Exception’s properties are used to formulate error messages indicating a caught exception. • Property Message stores the error message associated with an Exception object. • Property StackTrace contains a string that represents the method-call stack. • When an exception occurs, a programmer might use a different error message or indicate a new exception type. • The original exception object is stored in the InnerException property. • Other properties: • HelpLink specifies the location of a help file that describes the problem. • Source specifies the name of the application or object that caused the exception. • TargetSite specifies the method where the exception originated.

13. Common .NET Exceptions • The CLR generates SystemExceptions, derived from class Exception, which can occur at any point during program execution. • If a program attempts to access an out-of-range array index, the CLR throws an exception of type IndexOutOfRangeException. • Attempting to use a null reference causes a NullReferenceException.

14. FCL-Defined Exceptions • System.Exception • System.ApplicationException • System.SystemException • System.AccessViolationException • System.ArgumentException • System.ArgumentNullException • System.ArgumentOutOfRangeException • System.FormatException • System.IndexOutOfRangeException • System.InvalidCastException • System.IO.IOException • System.IO.FileNotFoundException • System.NotImplementedException • System.NullReferenceException • System.OutOfMemoryException

15. Determining Which Exceptions a FCL Method Throws • Example:Convert.ToInt32 • Search for “Convert.ToInt32” in the Index of the Visual Studio online documentation. • Select the document entitled Convert.ToInt32 Method. • In the document that describes the method, click the link ToInt32(String). • The Exceptions section indicates that method Convert.ToInt32 throws two exception types.

16. What are Exceptions? • They are not an “exceptional event”, a rare event that occurs. • They are not just errors. • They are specific results returned when a method could not complete its task. • Example: when should Transfer throw? public class Account { public void Transfer(Account from, Account to, decimal amount) { … } } • When the Transfer method detects any of such possible conditions and cannot transfer the money, then it should notify the caller that it failed by throwing an exception.

17. Choosing the Exception to throw • When implementing your own methods, you should throw an exception when the method cannot complete its task. • Associating each type of malfunction with an appropriately named exception class improves program clarity. • What Exception-derived type are you going to throw? • You must select a meaningful type • You can select a type defined in FCL that matches your semantics • If not, you may need to define your own type • Your exception type hierarchy should be shallow and wide: that is, create as few base classes as possible • What string message are you going to pass to the exception type’s constructor? • If the exception is handled, no one will see this exception message. • If the exception is unhandled, then the code will probably log this message and a developer would want to understand what went wrong using this message. So the message should give enough detail as possible. • Message does not need to be localized.

18. User-Defined Exceptions • User-defined exception classes should derive directly or indirectly from class Exception of namespace System. • Exceptions should be documented so that other developers will know how to handle them. • User-defined exceptions should define three constructors: • a parameterless constructor • a constructor that receives a string argument(the error message) • a constructor that receives a string argument and an Exception argument (the error message and the inner exception object)

19. User-Defined Exception Example • SquareRootTest

20. Do not catch everything! try { // code that might fail… } catch (Exception) { … } • How can you write code that can recover from all situations??? • A class library should never ever swallow all exceptions. The application should get a chance to handle the exception. • You can catch all exceptions only if you are going to process it and re-throw it again.

21. Benefits of Exceptions • The ability to keep cleanup code in a dedicated location and making sure this cleanup code will execute • The ability to keep code that deals with exceptional situations in a central place • The ability to locate and fix bugs in the code • Unified error handling: all .NET Framework classes throw exceptions to handle error cases • Old Win32 APIs and COM returns a 32-bit error code. Exceptions include a string description of the problem. • Exceptions also include a stack trace that tells you the path application took until the error occurred. • You can also put any information you want in a user-defined exception of your own. • The caller could ignore the error returned by a Win32 API, now the caller cannot continue with exceptions. If the application cannot handle the exception, CLR can terminate the application.

22. Exercise • Modify your Homework 2 to now handle exceptions thrown by file stream classes • Also create new exceptions to be thrown from the ItemsFile class for each method for error cases like: • File cannot be opened for some reason • New item cannot be added for some reason • Item to be deleted is not found in the file