This blog I believe will probably be quite useful to anyone that writes code and wants to learn the proper use of exceptions.
Never throw type System.Exception:
Always throw an exception of a predictable and descriptive type (preferrably documented with
<exception> tags, more on that later) and use the Message property to communicate meaningful data to anyone who has the misfortune of catching your exception 10 steps up the stack trace with no clue what your code is doing in the bowels of that ancient library. or more practically, so that when you get a screenshot of the exception dialog without a stack trace you will know what failed.
Never catch type System.Exception:
If you are going to catch an exception, catch the type of exception you are expecting and handle the failure that caused it. Catching all exceptions tend to result in an impossible to debug bug when your error handling code sweeps a really bad error under the rug because you thought it was something else. The only exception to this rule is when you are catching an exception to launch a fatal error dialog.
Check for NULL:
Almost as bad as throwing a System.Exception is letting code you are calling throw a plain NullReferenceException with no message. Think of the debug examples listed above. If someone passes you a null argument that doesn’t make sense to be null, you throw an ArgumentNullException and give at least the paramName argument. If you get an unexpected null in some other way then you can throw a NullReferenceException if no other exception describes the cause of the failure better, but include a useful message. On a related note, your summary comments should have parameters described and include a statement that they cannot be null if this is the case.
Library classes should never fail silently:
Do not handle errors by returning an error code or true for success, false for failure etc. Return vales can be accidently ignored and when the failure happens it will be a near impossible bug to track down. Failures should kill the app or be handled in a way that makes since. Usually, for something that is not UI specific, that means forcing the UI to handle the failure an making sure that those consuming your code know it can fail. Which brings us to the next part.
Document exceptions that can be thrown:
One of the few awesome features of Java is the requirement that methods declare what eceptions they can throw. The more I work with poorly documented libraries, the more I wish this requirement existed in C# as well. While C# does not require it, it does provide means for documetning it and all the .net core libraries provide documentation of what exceptions can be thrown. The syntax for reporting your exceptions is as follows:
/// <exception cref="SampleException"> /// Normally, a discussion on why this exception is thrown would go here. /// </exception>
You can have one of these blocks for every type of exception your code throws and I highly recommend that you do..
BlogSlayer is the official blog of FrogSlayer, a custom software product development shop in Bryan/College Station, Texas. Our specialty is getting your product to market in 90 days or less. If you would like a free consultation for your project or big idea, email us at firstname.lastname@example.org. You can also connect with us on Twitter, Facebook, or LinkedIn.