The tech is not the problem

The other day I jumped feet first into one of those pedantic debates that never ends: exceptions.  With my stance that throwing exceptions for flow control is a correct use of exceptions (following the lead of .NET cofounder, Jeffrey Richter). This post is not about the rights or wrongs of using exceptions.  Someone responded that exceptions for flowcontrol makes it very difficult to know what exceptions to actually catch and handle.  This is a valid point.  

But the that is not a problem with the use of exceptions.  Its a process problem.

The purpose of processes is to simplify engineering day to day work.  The process fails when an engineer spends more time getting work done than they need--such as this case being in the dark as to what exceptions to handle.  The solution is to improve the process, not reduce or eliminate the use of exceptions.

Code reviews should ensure that all exceptions that can be thrown are documented.  This can be done in code comments, or better yet, in external documentation.  This documentation should be part of the definition of done for any feature or module.  If the documentation is not complete, the code is not done.  

Tests should verify that the documented exceptions are actually thrown.  This way, anyone using the code can know exactly what exceptions to expect and handle.

If the code consumed is part of an imported library, the same process applies.  The exceptions that can be thrown should be documented and tested.  Sans any documentation, there's always IL inspectors and decompilers that can be used to determine what exceptions are thrown.  Sure, it is more work, but it also provides ROI in that it simplifies the work of consuming the library at a later date.

If all of this applies and someone is still struggling with consuming code, then you have training issue. 

The answer is not to avoid using exceptions.   Changing how you use exceptions can actually make your code more nested, and even more brittle--which in the lead slows down engineering work, not enhancing it.

This is a common theme on my blog:  how engineering tends to make decisions that end up having negative consequences later on.  Engineering too often relies on technology to solve problems that are better solved outside of the tech stack.

Using exceptions for flow control is not inherently bad.  Without a process to manage the perceived complexity it introduces, it can lead to confusion and bugs and longer delivery times.  In this scenario, the solution is not to avoid using exceptions for flow control, but to improve the process around their use.