undefined | Better HN

0 pointscletus5y ago0 comments

Yeah it's reasonably common for people to try and salvage checked exceptions by saying people are doing them wrong but at some point you realize the best you're doing is trying to put lipstick on a pig.

Here's a bigger problem: checked exceptions pollute your API and expose implementation details. Consider an API that stores and retrieves objects. A particular implementation does so by writing them to a database via JDBC so you get SQLExceptions. You have two basic approaches:

1. Include SQLException in your function signatures so the caller can deal with it. This exposes the implementation detail; or

2. You can hide it by transforming that checked exception into something specified for your API. At this point, what benefit have you gained from SQLException being a checked exception? You're hiding that detail.

For (1), you're baking checked exceptions into your function signatures such that it can be really difficult to change later on.

If you sit down and think about the practicalities the argued upsides of checked exceptions are essentially nonexistent and unchecked exceptions are actually strictly superior.

Here's another pattern that happens with checked exceptions in Java:

    try {
      doSomeSQL();
    } catch (SQLException e) {
      // do nothing
    }

You will see people do this all the time because they don't want to deal with the checked exceptions. A better catch-clause is:

    throw new RuntimeException(e);

You can argue people shouldn't do the first and they shouldn't but unchecked exceptions will simply bubble up unless you deliberately swallow it. That's a way better default. Defaults matter.

0 comments

4 comments · 3 top-level

Mindless21125y ago· 1 in thread

> checked exceptions pollute your API and expose implementation details

Exceptions aren't an implementation detail. They're part of the API contract. Checked exceptions make this explicit, but people don't like that because error handling is hard and pretending that errors don't happen is easy.

merb5y ago

I argue against that. because the problem is not that error handling is hard, the problem is that it is mostly unnecessary. Basically if you would write a hello world that writes directly to STDOUT you would need to handle IOException, guess what? it's basically useless to handle any kind of IOException in that case, because guess what? if your i/o device for output to display is broken you can only let your program crash. and that is the most common case how most exceptions are handled. and thats excalty where the k8s hype is about.

fail fast, start from scratch. you can't handle a network error in your application, but you can basically kill everything that lost network access to your database and recreate it where database access is still possible. but you don't need to do that in your application, your infrastructure should handle these and thats why most checked exceptions in the java stdlib are basically stupid. 90% of the stuff reuses exceptions for ease of use but 90% of the stuff should be runtimeexception and 90% of them should split them up, between stuff that I COULD recover from and from stuff that I can't (i.e. SSLException should be split into validation of certificate exceptions and protocol violations!!! that mostly can't be handled without reconfiguring the JVM!!!! I mean there is a SSLProtocolException but it's basically useless since it reports a totally different thing..)

zeroimpl5y ago

I've literally never seen somebody catch a SQLException and do nothing with it - you quickly learn that just doesn't work, and it would never pass a code review.

With respect to exposing implementation details:

If the caller is the one who passed in the connection, then it makes complete sense to throw a SQLException so the caller can deal with it.

If the connection was opened in your method, then yes you probably should wrap it, handle it properly and clean up the connnection, and then throw a different exception.

The only time it's ambiguous is if the connection came from an instance variable. That's often a poor design, but usually means it came indirectly from the caller and so it still makes sense to throw SQLException.

In general, SQLException works fairly well as a checked exception. If some code generates a SQLException, your transaction failed and you should generally abort it (or you can check the specific error code if you are prepared to handle anticipated failures such as a duplicate key error). If it generates any other exception, you can continue working with the database (such as saving the failure status to a table).

ragnese5y ago

> You can hide it by transforming that checked exception into something specified for your API. At this point, what benefit have you gained from SQLException being a checked exception? You're hiding that detail.

This is what you should do, yes. And I gained from SQLException being checked, because I am reminded by the compiler that I need to wrap it in my API's Exception value. If I can't handle it or don't think a caller of my code can/should handle it, I'll wrap it in an unchecked exception and rethrow.

> Here's another pattern that happens with checked exceptions in Java:

I mean... what do you want? You can't fix stupid. That's a really obvious mistake that should never ever make it past code review. I can shit on Java for making everything nullable and thus actually difficult to figure out if you should null-check something. But I can't shit on Java for someone writing code like that.

j / k navigate · click thread line to collapse