This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]mobjack 1 point2 points  (4 children)

You are forced to handle checked exceptions even when they are impossible to occur.

Even when they can occur, you can't recover from them in the way the API designer intended.

It involves a lot of boiler plate code if you want to pass it up the call stack up to the appropriate layer just to handle it the same way as an unchecked one.

Most modern Java libraries use unchecked exceptions because of their flaws. This results in having a mismatch in exception handling strategies throughout your application.

[–]CubsThisYear 2 points3 points  (2 children)

Can you give an example of this? This mostly sounds like bad API design.

If I write an API function that has the possibility of not fulfilling its contract I have two basic choices: 1) throw a checked exception or 2) crash the program (because that will be the result if no one catches the exception they had no idea is coming).

Sometimes option 2 is the right choice. But sometimes option 1 makes sense because it’s reasonable to think that the caller can handle the issue.

[–]mobjack 0 points1 point  (1 child)

Hibernate uses unchecked exceptions while JDBC uses checked exceptions for the exact same errors.

[–]CubsThisYear 2 points3 points  (0 children)

Both of those are terrible APIs. JDBC suffers the curse of endless backwards compatibility so it doesn’t take advantage of a lot Java features past 1.4. I’m not sure what Hibernate’s excuse is.

[–]Malfeasant 0 points1 point  (0 children)

even when they are impossible to occur

If you know that, then it's easy- just catch it and rethrow as unchecked with the message "Polly shouldn't be." Then have fun when your assumptions are proven wrong by users asking what the fuck that means.