1. Syntax, semantics, and pragmatics
Exceptions
Syntax, semantics, and pragmatics
Exceptions /Anders Børjesson

2. Syntax, semantics, and pragmatics
How it looks, i.e. how we have to program to satisfy the compiler.
Semantics
What it means / how it works
Pragmatics
How to use it in the proper way.
Exceptions /Anders Børjesson

3. Exceptions /Anders Børjesson
Introduction
Exceptions are thrown from methods when something exceptional (un-expected) happens.
Whether something is exceptional or not is a design issue.
Is it exceptional to search a list for a non-existing element?
Probably not
Don’t throw an exception, return null
Is it exceptional to open a non-existing file?
Probably yes
Throws FileNotFoundException
Exceptions /Anders Børjesson

4. Exception related syntax
try { … } catch (SomeException ex) { … }
In the try block you call methods that might throw exceptions
In the catch block you handle the exceptions thrown in the try block (if any)
try { … } catch (SomeException ex) { … } finally
The finally block is executed after the try block (and the catch block) no matter if there was an exception, or not.
Usually used to close resources like files, database connections, network connections, etc.
try { … } finally
Sometimes you omit the catch block
If you only want proper close of resources
Exceptions /Anders Børjesson

5. Exceptions /Anders Børjesson
The using statement
With the using statements resources will automatically be opened and closed.
No need for finally { …. resource.close() … }
Example: TryingUsing
Syntax
Using (declare + open the resource) {
… use the resource …
} // resource is automatically closed.
Works on all resources (classes) implementing the interface System.Idisposable
Has a single method void dispose()
Source
Exceptions /Anders Børjesson

6. Exceptions /Anders Børjesson
Throwing an exception
If something un-expected happens your method can throw an exception.
You really throw an exception object, i.e. an object of a class that extends the class Exception
Syntax: throw new SomeException(…)
Semantics: You leave the method.
More syntax: No exception declarations in method signatures
Public int divide(int a, int b)
The return type is declared, in this case int.
However, the type of exceptions that might be thrown is not declared
In this case DiviceByZeroException
Exceptions /Anders Børjesson

7. Exceptions and the call stack
Every program has a call stack.
The main() method is the bottom of the call stack
Every method call pushes a new element on the call stack
Method return pops an element of the call stack
Throw an exception pops an element of the call stack
The popping continues until the exception is caught
Or if it is never caught the main() is popped from the stack, and the program terminates
Exceptions /Anders Børjesson

8. Some exception properties
Message property
Text message explaining what is wrong
StackTrace property
Shows all the methods that was popped of the call stack
InnerException property
Used for exception chaining (more on that later on)
Exceptions /Anders Børjesson

9. Sequence of catch blocks
A single try statement may have several catch blocks.
Each catch block handling a separate exception
Catch more specific exceptions before general exceptions
Example: catch the specific FileNotFoundException before the general IOException
Otherwise your program does not compile
And it does not make sense!
Example: TryUsing -> ReadFirstLine -> Main
Exceptions /Anders Børjesson

10. Different kinds of exception handling
Ignore (an empty catch block)
Generally a bad idea
Does it make sense to continue program execution after ignoring the exception?
If you really want the catch block to be empty, you should leave a comment for the human reader
/* this catch block is intentionally left empty */
Handle
Catch and do something.
If you can’t do anything better than Console.print(…), don’t do it!
Does it make sense to continue program execution after the catch block?
Partly handle
Catch the exception
Do something (could be Console.print(…))
Throw the exception (or another exception)
Exceptions /Anders Børjesson

11. Some commonly used exception classes
NullReferenceException
You tried to call a method on a object reference which is null
Student st = null; …
St.someMethod(); // NullReferenceException
New throw a NullReferenceException
ArgumentException
You have a problem with a parameter (argument) to a method
ArgumentNullException
Parameter with value null is not allowed
ArgumentOutOfRangeException
Parameter value is out of range
IndexOutOfRangeException
You have a problem with our array index
OutOfMemoryException
You have created to many object
StackOverflowException
To many method calls. Normally because a method is calling itself to many times.
More detailed exception
More detailed information about the problem
Easier /better handling of the problem
Exceptions /Anders Børjesson

12. Making your own exception types
It is really easy to make another exception type, just extend the class Exception directly or in-directly
Class MyException : Exception { … }
Normally you your exception class will have a few constructors.
Example: TryingUsing
The model layer should include a homemade exception
Example: A hotel reservation system should have a HotelReservationException
Technical exceptions should stay at the technical layers
Catch (TechException ex) { throw new ModelException(ex); }
Exceptions /Anders Børjesson

13. Exception chaining + exception translation
If you want to catch a technical (low level) exception and instead throw a model exception (high level) you have two possibilities
Exception translation
Catch (TechException ex) { throw new ModelException(ex.Message); }
The ModelException holds the same message as the TechException
Exception chaining
Catch (TechException ex) { throw new ModelException(ex); }
The ModelException holds a reference to the TechException
The property InnerExceptions holds the reference to the inner exception
Example: LayeredLibrary
Exceptions /Anders Børjesson

14. References and further reading
MSDN Handling and Throwing Exceptions
Exceptions /Anders Børjesson