Unhandled exceptions are the bane of any application, especially those that run without user interaction. Ideally, the compiler would detect and alert developers to these potential issues, but current .NET compilers cannot even determine which exceptions might be thrown.
To address this Red Gate has released Exception Hunter. This tool analyzes methods to determine which exceptions they can throw. The reports can be viewed interactively or chained to an automated build process like CruiseControl.
Like most Red Gate software, Exception Hunter has a simple and straightforward interface. But unfortunately, simplicity does not always translate into ease of use. While the tool is capable of generating reports, it can only do so from the command line. This simple task isn't to be found anywhere in the GUI.
More frustrating is that the method list does not indicate which methods actually throw exceptions. Some methods are in bold, but that just means the method is not inherited form a base class. The user has to drill into each method separately.
All this could be overlooked except for one thing, the number of false positive is ridiculously high. Consider this simple VB application
The exceptions these few lines can throw include:
- ArgumentException 6
- ArgumentNullException 4, 6
- ArgumentOutOfRangeException 4, 5, 6
- FormatException 4, 6
- IndexOutOfRangeException 6
- InvalidCastException 6
- InvalidOperationException 6
- ObjectDisposedException 6
- IO.PathTooLongException 6
- NotSupportedException 6
- NullReferenceException 6
- OutOfMemoryException 4, 5, 6
One could only imagine the noise a non-trivial application would generate.
While effective exception analysis would be a boon to the industry, Red Gate's Exception Hunter demonstrates that we just are not to that point yet. And one has to wonder if this is even a solvable problem.