Hacker News Reader

Comment by arockwell | Hacker News Reader

I agree with his premise that exceptions get misused by "average" developers. Where I work I see a lot of swallowed exception, which has lead to some evil bugs. I have also encountered some code that's literally impossible to write meaningful test code for because every exception is swallowed and there's no return code.

However, I don't think that going back to checking return codes solves anything. Most of the problems I see at work are related more to checked exceptions than using exceptions in general. Thankfully, most of java frameworks I use have moved towards making everything an unchecked exception.

View on HN

I only write Java on very rare occasions (usually for clients that don't care if the code is throw-away quality), and so I usually end up with a "throws Exception" after every method. Horrible, but hey... it's not my fault Java sucks so hard.

No offense, but yeah: that's pretty horrible. Checked exceptions are one of Java's few true innovations. Used properly, they force you to handle errors in the spots where they occur. What you're doing is a 1:1 equivalent of ignoring the error codes returned from your C functions. That's just never the right way to do thing.

Exceptions are not meant to be handled where they occur, that's why they unroll the stack. For the most part, you can't recover from an exception -- you just abort whatever you're doing, print an error message, and let the user try something else. Checked exceptions cause developers to re-interpret the exceptions or just swallow them -- neither is a benefit.

Exactly. If the database server blew up, there's nothing my program can do. I could try reconnecting, and some libraries do, but that doesn't usually help anything. Once the server is back up, the Fibonacci (or exponential) back-off is so high that's it's faster to just restart the program manually. So usually, dying is easier for everyone.

A good thing about exceptions is that you can place your handler where you know it's best, that could be in the top level. Unless you use Java so you are forced to fill this burocratic method passport all along the way. That's no good and putting the word "innovation" there freaks me.

On a large CRM-type application I worked on in the past, database constraints were used to enforce stuff like unique login IDs. Yes, some validation could be done in the UI but that was the way it was done.

When a user tries to create a user with a login ID that already existed, the database constraint is encountered and an Oracle exception is thrown. It is caught and and packaged up through the application stack until it becomes an application-level exception. The end user sees a localized, friendly message instead of seeing a raw, nasty ORA error message. I'm not sure how this could be done without checked exceptions.

You can use unchecked exceptions exactly the same way with as checked exceptions. The difference is that you can ignore them and let them propagate up when it makes sense.

A real-world example of your use case:

The Spring framework repackages all SQLExceptions into a custom data access exception hierarchy. So, if you choose, you could catch a DatabaseConstraintException (or whatever the appropriate exception is, I'm not sure off the top of my head), and throw an application specific exception like InvalidLoginId.

Thanks. That's cheating, you can't use magic :) We use Spring in our current app and I don't know how it does the cross-cutting it does; it just does.

Propagating exceptions without handling them anywhere is bad, but IMHO still better than ignoring an error code.

If you ignore an error code, the program will continue but probably fail later or just be wrong in subtle ways, generate corrupt output or whatever. An unhanded exception OTOH will just stop the program. At least then you realize you have a problem, and where it originated.

Empty catch-clauses however, are just as bad as ignoring an error code.

That's pretty ugly, although I've seen a lot of that style of coding at my workplace as well. The problem is that there generally isn't anything useful to do once you catch the exception besides throw up an error page. You're probably bother off either throwing RuntimeExceptions or wrapping exceptions as RuntimeExceptions.

There are other return codes besides ints. E.g., replace a function that returns an int or throws an IOException with one that returns an Either<int, IOException>.

Reply on news.ycombinator.com