56: C# Exceptions. Finally Required.

Errors will happen. The question is how will you deal with them? The QA Friday from 2015 Dec-11 talked about this question. This episode explains C# exceptions and how they are different from C++ exceptions. When should you use exceptions in your code? You might find some guidance that tells you to place a try/catch or a try/catch/finally block around any method that can throw an exception. I advise you to start a try block for either or both of the following reasons: You know how to handle an exception either completely or partially. As long as you have some meaningful contribution to make if you were to catch a specific exception type, then go ahead and setup the try block and add your catch statement to catch that exception. You have some code that you want to make sure always runs either with to without an exception. Then setup the try block and add a finally statement so you can place your code in the finally block. This will run either after all the code in the try block finishes normally or after an exception is thrown and potentially caught by one of the exception handlers. In C#, you can throw anything that derives from System.Exception including System.Exception itself. I advise against throwing System.Exception directly. It doesn’t provide any additional type information and creating your own type is just too easy. There are also many useful and recommended exception types already defined for you in the .Net Framework. Here are some of the common types: InvalidOperationException – Throw this type when you want to show that a method should not be called while the class instance is in a particular state. ArgumentException – Throw this when you find an argument passed to one of your methods that’s not right and not due to one of the next two scenarios. ArgumentNullException – Throw this when you find an argument passed to one of your methods that’s not right because it’s null. ArgumentOutOfRangeException – Throw this when you find an argument passed to one of your methods that’s not right because its value is either too small or too large. NullReferenceException – Don’t throw this. Just fix the problem. This exception represents a coding bug that needs to be fixed. You might want to catch this exception to log the problem. OutOfMemoryException – Don’t throw this exception either. If you catch this exception, then you might be able to recover by getting rid of memory you don’t need and trying the operation again. The computer system is likely very unstable at this point so you may not be able to recover. Listen to the full episode or read the full transcript below. Transcript Exceptions in C# are even more integrated into the language than in C++. This is because they’ve been part of the C# language from the very beginning. You might find guidance in other places and even in the documentation from Microsoft that tells you to use a try block around any method that could throw an exception. You should really only begin a try block for these two reasons: ◦ #1 Is whenever you know how to handle an exception. This doesn’t mean that you have to fully handle the exception because you can still rethrow an exception if you want to let it be caught again at some other location. But if you have some value that you can add to the program by catching one or more exception types, then go ahead and start a try block so you can add your catch statements. ◦ #2 Is whenever you need some code to run always no matter what. You see, whenever an exception is thrown, the code that comes after that gets skipped. It’s like when you throw a ball over other people so they can’t reach it. When you have code that needs to run no matter if an exception is thrown or not, then you need a finally block. The structure of try/catch/finally starts with the keyword try and then opening and closing curly braces. Any code inside the curly braces t