The stack trace that doesn’t mean anything

We’re using an open source java app to help with searching on my current project and when I start it up (through cygwin – must… stop… developing… in… windows…) it throws up a bunch of stack traces. The first time I saw this I thought “holy crap, I must have configured it wrong.” And I was right. But then I configured it correctly and I was still getting a few stack traces on startup. I spent an hour or so trying to fix the problem before I remembered that lots of times a Java app will thow some errors at ya just for fun and I started up the rails app, navigated to the search, and it worked fine. Nice. So I just learned to ignore those stack traces.

Can you see where this is going?

Yep, later the search stopped working in a spectacular way that took down the whole app. Except I wasn’t sure it was the search breaking it. And I lost a bunch of time because I was ignoring the errors that were telling me something was wrong. They were different errors than the usual ones, but I was so used to hitting enter and watching a big stream of stuff fly by that I didn’t look at it.

Errors that are not critical errors need to be stuffed in a log file. Otherwise you’re training your users to ignore your output. Take a look at how Mongrel starts up:


** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment...
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready. INT => stop (no restart).
** Mongrel available at 0.0.0.0:3000
** Use CTRL-C to stop.
A few lines and no random crap. Want to know the details? There’s a log file for that.

Neal Ford has been having similar problems with garrulous software.

Comments

Popular posts from this blog

What's a Good Flog Score?

Point Inside a Polygon in Ruby

SICP Wasn’t Written for You