Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why checked exceptions failed

borretti.me

Post reply on HN
Print view View original

81–90 of 318 posts

Re: Why checked exceptions failed

#81

Post by EricRiese »

tom_ wrote: post #74
croes wrote: post #19

Earlier quoted context omitted.

>you would have to catch the root Exception class, which everyone agrees is a bad idea. It's a bad idea to catch an unexpected exception?

You run the risk of swallowing something interesting. This was always the problem with C# exceptions to my mind: there was just one mechanism for reporting errors, which covered everything from the most non-erroneous of events, that aren't even errors, such as file not found or invalid file name encoding or failed to write data to file or socket error during write, to stuff that absolutely should cause the program to…

> the most non-erroneous of events, that aren't even errors...

You're applying a value judgement that the language makers can't and shouldn't make for you. Whether the error is innocuous or malicious, the happy path of your code cannot proceed and needs explicit handling by the programmer.

Re: Why checked exceptions failed

#82

Post by funnymony »

invalidname wrote: post #64
funnymony wrote: post #56

Earlier quoted context omitted.

> important failure that can't be dismissed But importance of the failure is determined completely by the program, not the library. Grep fails to open a file for reading -> message the user and exit Nuclear reactor controller fails to read important a file -> initiate reactor shutdown or something. If file read is critical, you have to handle failure no matter what the interface is. Because you know that disk can fai…

Grep isn't a library. It's a program. Some things are important in the library level e.g. an SQL exception must have proper cleanup. However, in some cases you don't want to cleanup. You might want to try a different approach so generic cleanup code isn't necessarily the right thing. E.g. in the case of grep. Say I wrote grep and want it to be generic. I wrote a library that implements grep. Then I write a grep GUI t…

Yes, grep and nuclear reactor controller, and your gui grep are applications.

They all use library for file reading.

As author of file reading library you don’t know how critical is the failure to open a file or how it should be handled. My point was that You know those things only at application level.

So it feels a bit misguided to decide at library level which failures are important. (I.e. which are checked vs which are unchecked)

> But as API authors how can we make sure

First thought: documentation. (which is required for both, checked and unchecked exceptions).

But overall, it’s not library author’s responsibility or ability to “ensure”. You can’t force correct handling of exception. At best one can make it a bit more annoying to ignore, and convenient to do the right thing.

My view:

- all exceptions should be unchecked

- assume all code throws

- if “log and exit/continue” is not enough and you need to know exact exception types, dig into the docs.

- read docs during lib version upgrades

Re: Why checked exceptions failed

#83

Post by EricRiese »

Java has a lot of "throwingness polymorphism". You can extend an interface to say a method throws a subclass of the Exception thrown by the parent interface method. You can extend an interface and say that that method actually doesn't throw an exception at all.

  interface NonThrowingAutoCloseable extends AutoCloseable {
    void close();
  }
You can also declare that you throw a generic exception type

  interface ThrowingSupplier {
    void get() throws E;
  }

Re: Why checked exceptions failed

#84

Post by wiseowise »

breadwinner wrote: post #54
EMM_386 wrote: post #21

Earlier quoted context omitted.

> Someone made a change in a function I was calling, and it started throwing a new exception. If it has nothing to do with your code, why not either let it bubble up the stack or try/finally it to do whatever clean-up you need to do before re-throwing it and letting it move on to a global logger or similar. If it is something you care about you can always catch the specific exception type and handle it. Maybe whoever…

Imagine that the functionality implemented by your method is very important. This functionality should not be needlessly aborted. If so you want to be aware of errors you can recover from, correct? This is why checked exceptions are helpful. It gives you a guaranteed-by-compiler list of exceptions and you can decide which of those you should recover from.

Yes. But it’s not as simple as checked=good, unchecked=bad and vice versa.

Re: Why checked exceptions failed

#85

Post by masklinn »

he0001 wrote: post #48
masklinn wrote: post #23

Earlier quoted context omitted.

They were abandoned long before “the functional paradigm”. They started being a problem when the Java community decided interactions should go through interfaces over concrete types, and it only got worse with genetics then functional streams.

Not sure about that. Reinhold said so explicitly during a conference when they launched Java 8. I don’t see interfaces over concrete types as an issue here.

That checked exceptions are an issue with interfaces is literally what TFA is about.

Re: Why checked exceptions failed

#86

Post by ablob »

breadwinner wrote: post #69
dbrueck wrote: post #66

Earlier quoted context omitted.

I stopped using Java a long time ago, and so I assume the language has gotten better since then, but early on at least it felt like Java almost took pride in making the developer jump through extra hoops. Compared to many other languages, using Java just made me feel tired. Checked exceptions - a feature that seems to be a cost to the developer 100% of the time while being a benefit far less than 1% of the time - is…

Some people say the same about strong typing. Like, why do I have to write down the type of every single parameter or variable? Java is making me jump through hoops! The point is, if you don't need the rigor of a strongly typed compiled language, there are other languages you can use. Perhaps a bash script is all you need.

In strong typing you don't have to (See type inference). It just means that the shape of the data/object you receive is known to you.

That a lot of languages force you to write it out is not an inherent property of strong typing.

Re: Why checked exceptions failed

#87

Post by wiseowise »

breadwinner wrote: post #69
dbrueck wrote: post #66

Earlier quoted context omitted.

I stopped using Java a long time ago, and so I assume the language has gotten better since then, but early on at least it felt like Java almost took pride in making the developer jump through extra hoops. Compared to many other languages, using Java just made me feel tired. Checked exceptions - a feature that seems to be a cost to the developer 100% of the time while being a benefit far less than 1% of the time - is…

Some people say the same about strong typing. Like, why do I have to write down the type of every single parameter or variable? Java is making me jump through hoops! The point is, if you don't need the rigor of a strongly typed compiled language, there are other languages you can use. Perhaps a bash script is all you need.

Java is the only mainstream language with checked exceptions and checked exceptions are nowhere near usefulness of static typing.

Following your logic, Java developers can now say “if you don’t like freedom of Java, use Rust/Haskell/Scala to validate everything at compile time”

Re: Why checked exceptions failed

#88

Post by invalidname »

funnymony wrote: post #82
invalidname wrote: post #64

Earlier quoted context omitted.

Grep isn't a library. It's a program. Some things are important in the library level e.g. an SQL exception must have proper cleanup. However, in some cases you don't want to cleanup. You might want to try a different approach so generic cleanup code isn't necessarily the right thing. E.g. in the case of grep. Say I wrote grep and want it to be generic. I wrote a library that implements grep. Then I write a grep GUI t…

Yes, grep and nuclear reactor controller, and your gui grep are applications. They all use library for file reading. As author of file reading library you don’t know how critical is the failure to open a file or how it should be handled. My point was that You know those things only at application level. So it feels a bit misguided to decide at library level which failures are important. (I.e. which are checked vs whi…

The library knows which are crucial issues that warrant your attention. A checked exception is a regular exception, it's just one that you can't miss and must either handle or propagate.

As a library author if you don't feel you need it then don't use it. It's optional. That's the beauty of it.

> First thought: documentation. (which is required for both, checked and unchecked exceptions).

Documentation > But overall, it’s not library author’s responsibility or ability to “ensure”.

Here we differ. Part of that is the domain we spend most of our time in. If you're giving me the example of grep then great, I see your point. Notice I'm giving an example of a high availability huge enterprise app.

Assuming all code throws forces overly defensive code which can cause a lot of problems. Yes, there's always a "catch all" but that's not a valid case for these sorts of apps.

Exit or continue are never enough for these sorts of applications.

We have dozens of dependencies and sometimes more. Some of them have mountains of documentations. Often we delay updates since these are enterprises. Going over 3 years of diffs in docs is just not a feasible option. Just the diffs in Spring Boot alone and all its dependencies would take several years.

Re: Why checked exceptions failed

#89

Post by scarface_74 »

invalidname wrote: post #79
scarface_74 wrote: post #76

Earlier quoted context omitted.

I did say > I can choose to handle the error myself

That's not a practical strategy in a large system. That's why we have exception handling. When we write generic library code we have no way of knowing how to handle an error in the full system. We want to concentrate some of the error handling while still making localized decisions in various places. E.g. I want metrics and observability details updated, yet I want locally to retry some behavior. Doing this every tim…

Isn’t that what I just said? It’s my responsibility as a consumer of the library to decide how to handle it?

Re: Why checked exceptions failed

#90

Post by invalidname »

scarface_74 wrote: post #89
invalidname wrote: post #79

Earlier quoted context omitted.

That's not a practical strategy in a large system. That's why we have exception handling. When we write generic library code we have no way of knowing how to handle an error in the full system. We want to concentrate some of the error handling while still making localized decisions in various places. E.g. I want metrics and observability details updated, yet I want locally to retry some behavior. Doing this every tim…

Isn’t that what I just said? It’s my responsibility as a consumer of the library to decide how to handle it?

Then I must have misunderstood you as speaking from the perspective of the library. Sorry.
Post reply on HN