The previous blog post received many comments, and this approves that the problem of handling errors\exceptions is palpitating. I thought I’m going to address practical points of errors\exceptions handling in the second part. But I feel I need to address comments of readers firstly.
Let’s consider the following comments:
- “…Exception is also a software layer just like Entity, Data access, UI, logging .. etc.” – Well, there is only one thing I can say about this. Exceptions handling, as well as logging, can’t be layered, because these problems are aspect oriented.
- A couple of readers mentioned that you should call File.Exists() before trying to open a file. Well, it’s a good practice, indeed. But don’t forget that true returned from that call doesn’t guarantee that File.Open() will not fail. As a rule of thumb, you should always catch exceptions when you’re making a call to OS, or to an external uncontrollable system.
- “Catching exceptions is expensive performance wise but the existence of a try catch block is relatively cheap.” – Jon Skeet’s laptop in 2006 was able to threw more than 100 exceptions per millisecond. It means for me, that if the performance of exceptions bubbling becomes a problem for you, then, possibly, you do something wrong regarding your errors handling. Possible solutions in this case are: TesterDoer pattern, TryDo pattern, returning errors (not throwing exceptions).
- “What a method can throw is pretty well understood” – This statement is a lie to yourself, you don’t know the whole list of exceptions from literally any call to .NET BCL. And if you don’t know what to expect, then what will you try to catch?
- “Don’t catch stuff inside your method, let it cascade up.” – You should handle exceptions as soon as possible, as close to the point where they arise as you can. Presume, that your higher logic called IncreaseSalary() method and as a response it receives ParsingException which has been raised from a method which is above IncreaseSalary() by two additional method calls in the call stack. How the hell your higher logic is intended to handle this exception? It’s completely impossible!
- “ONLY catch exceptions if you can do something meaningful.” – Excellent point, as well as useless. Unfortunately, sometimes we have to suppress noise exceptions. Especially when we are working with a network, for example (will you let SocketException bubble up to the caller? If you will, then I think you are in danger, cause those API users will find you and stab to death by knife).
- “I prefer to let an exception blow up with no try / catch. In this manner, I can fix the “Errors” instead of logging exceptions.” – First of all, you should always log all exceptions (almost all). Going this way, you will probably fix those “errors” at user’s cost. Most unhandled exceptions I have seen in my life, which crashed apps were not so scary and nothing would happen to the data in case programmer just caught that bloody exception. Yep, you can kill me for this statement, but I do believe in it. As I have already mentioned before, this depends on what type of app you are developing. I’ve seen so many apps on my Windows Phone which even didn’t carry any significant data within itself, but they crashed because of unhandled exceptions.
I’ll just post the following image, which I print screened just yesterday. I just went away from my notebook, and when I came back I got on my screen this:
Yes, I’m pretty sure Skype was about corrupting all the data (sarcasm).
I can provide in addition one case when throwing exceptions is useless: when a caller is making an async call and want to receive events from you. In this case, you can’t pass exceptions to the caller in a meaningful way, you have to pass Results inside events, you just don’t have control over the caller’s thread.
Sorry guys I can’t answer to everyone, cause I don’t have enough time. Next time, in a single shot, we will look at what we can do to handle exceptions correctly and how we can implement errors handling. We will consider some points of Microsoft’s official best practices manual regarding exceptions handling, and we will look at what Microsoft provides in the Enterprise library to us. Stay tuned; you don’t want to miss the next exciting post about exceptions\errors handling!
