Catching exceptions

Last night I had a bit of a problem: I had deployed db4otool.exe to a Windows Server 2008 build server, and it was failing during the build with error code -2. Nowhere could I find out what return code -2 actually means. Now the same program worked just find on my local Windows 7 server, operating on exactly the same collection of DLLs.


Now db4otool.exe is open source, and I could have downloaded the source code, got it compiling, installed the debug version on my build server, and then attempted to connect to it remotely with a debugger to identify the problem. Or I could have searched through the source for where the code returned -2. Neither idea seemed very quick or guaranteed.

So, after some additional thinking about the problem, I downloaded Process Monitor from technet, and ran it. It gathers information about what every process on the computer is doing, and then you can filter the gathered data to just what you’re interested in.

Usability aside:

Unfortunately, the program suffers from lots of usability issues, but it’s powerful nonetheless. For example, to start capturing data you click on a button that looks like this:

Clicking it converts it to a button that looks like this:

Alan Cooper talks about the usability problems of this approach in About Face 3, Chapter 21 on page 445: “Flip-flop buttons: A selection idiom to avoid”. Briefly, he says:

“Flip-flop buttons are an all-too-common control variant used to save interface real-estate. Unfortunately, this savings comes at the cost of considerable user confusion.
The problem with flip-flop controls is that they fail to fulfill the second duty of every control – to inform users of their current state.”

In this case, when you are not gathering data the icon shows as a magnifying glass with an X, so it is showing you the current state – but when I first saw it I assumed that it was already off, but I needed to find a button that would turn data gathering on. So Cooper is still right: the button can’t show you an action and be displaying the current state at the same time; he goes on to say, “Don’t use them”.

Anyway, back to diagnosing db4otool.exe:

I gathered data on the failing machine, and on my Windows 7 machine where db4otool.exe was working, and then I filtered it and compared the two (manually, I couldn’t find any way within the tool to do the compare). This was actually pretty easy.

Anyway, here’s the problem:

After doing quite a bit of work, db4otool.exe was trying to open Mono.Cecil.Pdb.dll, and failing (notice the “NAME NOT FOUND” in the result column). SO! I deployed the missing DLL to the build server and db4otool.exe immediately worked just fine.

I should have received a bug huge ugly and incredibly helpful error message: System.IO.FileNotFoundException which contains details on exactly which DLL cannot be found! Instead, the db4otool.exe source code must have a generic:

catch(Exception e) {

block in it somewhere, and they simply return -2.

Point being, this is a great example of how catching System.Exception can make solving problems much harder! If the db4otool.exe authors had been more careful and caught only the exceptions they were expecting, I would have been able to solve this error in 30 seconds rather than 20 minutes.

Don’t catch System.Exception, unless you’re re-throwing it or displaying some really useful error message (and “-2” doesn’t count as useful…).

Leave a Reply

Your email address will not be published. Required fields are marked *