My debugging process

By Jamie | Posted Jan 8, 2018 | 2 min. (249 words)

Raygun may help you collect errors, but what do you do once you’ve got them? Fix them of course! That may be easier said than done though. When I get given an error to fix, I’ve got a bit of a process I go through that helps me fix bugs without creating new ones.

1) Collect data

A bug report is nothing without data. What happened, when did it happen, and what state was the system in just before the crash? Error logging helps (if you’re dealing with system generated errors and not user bug reports), as long as you put enough information in the error to find it later. If you are creating custom Exceptions, make sure they have something useful in them! There’s nothing worse than trying to debug a generic Exception with a useless message. “He’s dead, Jim” might be funny, but it isn’t going to help you in any way except giving you something easy to grep the source for.

My first port of call is the Stack Trace in Raygun – find the code that triggered the exception in the first place. Step up the stack trace till you find where dubious data might have come in. If you are dealing with a FileNotFoundException, find the stack frame where the filename is set. Or if it’s an ArgumentNullException, find where that argument is last set to something. The point is to find the bad input that

  1. Narrow down test case

  2. Reproduce in isolation

  3. Fix