December 2017

Personally, I like to be very strict when I’m making a program. When writing a method, and I think of an execution path that makes no sense, or should not occur, I throw an exception. Every thread has only one catch method in which the exception is handled.

This way, possible bugs are caught early, and are easy to resolve due to the data in the exception (exception type, message and stack trace).

This sounds great! But let’s enter the real world…

Imagine working on a product with several developers using the method above. The product is starting to get larger and consists of multiple components. One day, you, or one of your colleagues has been a bit careless and committed some code without testing it properly. No problem: an exception pops up! However, this exception now pops up for everyone that is working on the product. Even developers working on an entirely different component will be blocked until this one exception is solved.

Of course, this is a very crude example, and exception handling can be done per component or class. But from my experience it can be very useful to toggle the way exceptions are handled depending on the people using it.

This article on Code Project is about just that: toggling whether exceptions should be thrown, or handled in a different way.