logoalt Hacker News

flysand7last Monday at 8:17 PM2 repliesview on HN

Yeah, this kinda becomes a problem when the library you are using does not distribute its source code, so even if you get the line, this information is practically useless to you.

This has been my biggest problem with exceptions, one, for the reason outlined above, plus it's for how much time you actually end up spending on figuring out what the exception for a certain situation is. "Oh you're making a database insertion, what's the error that's thrown if you get a constraint violation, I might want to handle that". And then it's all an adventure, because there's no way to know in advance. If the docs are good it's in the docs, otherwise "just try it" seems to be the way to do it.


Replies

vips7Lyesterday at 10:43 AM

I think the real issue here is the lack of checked exceptions in most runtimes that use them. If you had compiler support for what’s thrown you would know in advance. Java has them, but they haven’t made them usable syntactically so programmers have rallied against them and any investment in that area is unpopular.

rorylaitilalast Monday at 8:24 PM

Yeah I agree with that, opaque errors from libraries are where this really sucks. The worst is when they swallow the original error and throw a generic exception instead.