Finding out reason of bug in code is not always easy thing to do. But it can be extremely hard if you have no idea what do with information that exceptions provide you. In this posting I introduce you weird artistic handling of exceptions and unfortunately this story comes from real life.
Years ago I had honor to witness one debugging session where one lengthy method threw NullReferenceException. It was actually one SharePoint form or web part that threw exception and the exption message was shown to user. The developer who worked on debugging this form or web part had also stack trace available for exception. One more thing to mention – two years of experience on .NET and university degree in software development were also written to CV of this guy.
Let’s start. NullReferenceException means that code is trying to use some object that is null. When attaching debugger to process then it is easy to step through problematic method and find out where exception occurs.
But what I saw was something new to me – the guy was just watching the message and then looking at different parts of source code to find out where things can go wrong. No, he was not investigating this one method but whole code in solution. Why is he doing something like this and why takes solving of this problem more time than half of day?
Well, here is how exception can be understood:
This is just arbitrary exception I stole somewhere from web.
- important information – this is the information that gives us details about bug and based on this information all debugging can be done,
- technical information – is… well… just techinal information like you can see when operating system crashes or ATM goes mad or your tablet has hardware fault – it is there, it is important but it’s just this technical information like all technical information everywhere else (maybe somebody needs it some day).
Of course, after short lecture about exceptions the problem got solved with ten minutes but the memory remains…