?

Log in

No account? Create an account

Previous Entry | Next Entry

I just spent 16 hours debugging a complicated, annoying and frustrating problem involving pages not loading in a database frontend, and being spontaneously logged out of a webmail application.

The culprit was the SQLite library (or its bindings to Ruby) being useless with error messages. An example:

#<SQLite3::CantOpenException: could not open database: unable to open database file>

This is not okay. First off, not saying what file is a little annoying, but thankfully, I can tell which file by context since this program only opens one database. Second, and most grievous, it doesn't say which system call failed (though I guess it's open(2))

and third, it doesn't say what error code. There's a reason errno.h exists, people! perror is your friend. A happy little "It didn't work" exception is no replacement for an exception that could read like this: #<SQLite3::CantOpenException: could not open database important.db: EMFILE: The process already has the maximum number of files open.></p>

I wouldn't be hacking about supposing it's a concurrency and locking issue. I'd be knowing that something's not closing files like it's supposed to, like I now know after stracing the process and seeing the real value of errno(3).

Don't do this, folks! Let exceptions carry the most information possible. If you code in C, use perror(3).

Now I get to see why my web framework isn't closing the database on a reload.

Tags:

Comments

( 14 comments — Leave a comment )
aechei
Aug. 29th, 2008 08:01 pm (UTC)
*blinks*

whoa.

i think you just broke my brain.
aredridel
Aug. 29th, 2008 08:02 pm (UTC)
*laughs* I am SUCH a geek. Like whoa.

I get so grumpy with avoidable bugs in software.
aechei
Aug. 29th, 2008 08:08 pm (UTC)
oh, me too. i just don't understand code.

my job actually involves a lot of programming-esque things, i just don't have to deal with code at all because i'm designing user interfaces. but it's all about making stuff efficient and intuitive.
aredridel
Aug. 29th, 2008 08:08 pm (UTC)
Oh, nice. *grins*

That's my favorite part of my work. This part is the one that makes me grumpy.
aechei
Aug. 29th, 2008 08:16 pm (UTC)
yeah, i bet.

I'm an information architect. you might be the only person on my friendslist who would have any idea what that means.
aredridel
Aug. 29th, 2008 08:17 pm (UTC)
*grins* Information architecture is freakin' awesome.

More people need to learn to do it well. It'd make my life a lot easier.
aechei
Aug. 29th, 2008 09:09 pm (UTC)
i shall try!

i'm hoping to gain a better understanding of programming along the way.
peaceofpie
Aug. 30th, 2008 01:59 am (UTC)
I know what it means!

I had to Wikipedia it to make sure I was right, but I was still right. :D
peaceofpie
Aug. 30th, 2008 02:01 am (UTC)
I love that there are people like you, so that people like me don't have to understand what you just posted. :)

*loves you*
peaceofpie
Aug. 30th, 2008 02:02 am (UTC)
And I promise that if I ever find myself coding in C, I will be sure to use perror(3).

I have no idea what I just promised not to do, but I'm sure it will be quite easy for me to keep this promise nonetheless. ;-)
(Anonymous)
Aug. 30th, 2008 07:31 pm (UTC)
"The perfect error message"
Back in 2006 I had the same experience, so I wrote this:
http://blog.netherlabs.nl/articles/2006/09/08/the-perfect-error-message

Bert Hubert
(Deleted comment)
aredridel
Sep. 1st, 2008 12:44 pm (UTC)
Ah, indeed. Even better point. (though at this point, stderr would have been fiiiine)
serishema
Sep. 3rd, 2008 12:34 pm (UTC)
This is all too common in the windows world as well. Windows Developers: always log the results of GetLastError() somewhere in addition to the failure message, and also call FormatMessage() passing the value returned by GetLastError() and trap SEH exceptions properly as well and at least log the details of the exception even if you can't handle it recoverably, this way your users will see something more helpful at diagnosing the problem than the standard windows crashed application behaviour.
( 14 comments — Leave a comment )