Why checked exceptions failed • Hacker News Board

Re: Why checked exceptions failed

#61

Post by funnymony » Sat, Jul 15, 2023, 1:54 PM UTC

invalidname wrote: post #53

scarface_74 wrote: post #47

Earlier quoted context omitted.

What “reminder” do you need to wrap your code? I can’t think of an instance that you wouldn’t wrap your code in a try/catch block around your code and either log and crash, log and continue, or for a specific exception that you know about, do “something”. But most of the time it’s the first two if you’re using RAII.

Let's say I write an API for handling IO. DB or File or networking or anything really. I get a failure, what do I do? I can throw an exception, but this is important how do I know the user of my API will actually do the cleanup after me. I can't do the cleanup since this is a part of an API not the actual usage of the API. How can I give the user of this API the right set of hint that "you need to pay attention to th…

Any chance you have a code/pseudo code example of this?

My naive take on this would be “just use raii/closable”. (But easily and likely, I misunderstood)

Re: Why checked exceptions failed

#62

Post by grumbel » Sat, Jul 15, 2023, 1:55 PM UTC

senkora wrote: post #44

grumbel wrote: post #29

Little aside, but I feel a lot of the drama surrounding exception could have been solved with a little syntactic sugar making their handling easier. Something along the lines of Perl's "|| die("...")" pattern would be a start (i.e. add some context and rethrow). In C++ I find it quite infuriating that try{} opens up a new lexical scope, which means you can't construct something, check for errors and move on, since th…

> In C++ I find it quite infuriating that try{} opens up a new lexical scope That’s an interesting point. I’ve never considered that because I haven’t worked with classes that regularly throw in their constructors. What situation do you have where 1) you are constructing classes that regularly throw in their constructors and 2) this is a recoverable error that 3) should be handled at the point where the class is cons…

Code like:

  QImage image("filename.png");

is pretty common. Qt solves this by not throwing an exception and using a Null image check:

  bool QImage::isNull() const

but that throws all the extra information that an Exception could provide away.

Re: Why checked exceptions failed

#63

Post by exceptotron » Sat, Jul 15, 2023, 1:55 PM UTC

grumbel wrote: post #15

PretzelPirate wrote: post #8

Earlier quoted context omitted.

Wouldn't it still be a problem? By putting "throws [Exception List]" in the interface, the interface making assumptions about the implementation details of every potential implementation. The interface can't know every exception that an implementation might throw, and using your example, some implementations may not use IP at all and won't throw those exceptions. It seems like you'd end up needing to list every possi…

> the interface making assumptions about the implementation details of every potential implementation. No, as you'd force the implementation to catch their implementation specific exceptions and rethrow them in the way defined by the interface. That's really the crux of it, when I call foo(), I expect to see a FooException when something goes wrong, since that's the only one I can meaningful react to. If I get an Imp…

I agree that, if you are working with checked exceptions, that’s certainly better than adding garbage to your interface.

But for many types of checked exception you just end up wrapping the underlying exception in a foo exception anyway.

I think you are right: if you are using exceptions for error handling, of errors you expect people to actually deal with, this is currently a reasonable (if painful) option to ensure exhaustive analysis of returns — which most people agree is a good thing these days I think, what with mainstream popularization of options etc.

Re: Why checked exceptions failed

#64

Post by invalidname » Sat, Jul 15, 2023, 1:57 PM UTC

funnymony wrote: post #56

invalidname wrote: post #24

Earlier quoted context omitted.

We have it in Java too. For us it's try-with-resources and has nothing to do with checked exceptions. Checked exceptions remind you that you need to wrap the code and need to take that into account. They also force you to declare that an exception is thrown if you don't want to handle it in the current method. That's important as the signature of the method carries an important failure that can't be dismissed and is…

> 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 tool. OOps. It exits if the file isn't found instead of showing an error dialog. With exceptions this is communicated up the layers. That's their purpose.

If I'm writing generic code and that code is used in a nuclear reactor I would very much not like my failure code to decide what to do. That's why we have exceptions, they punt the responsibility to the next person up the chain. I have no idea how to initiate a nuclear reactor shutdown etc.

But as API authors how can we make sure the person who writes the code up the chain knows that this is something crucial?

Re: Why checked exceptions failed

#65

Post by kaba0 » Sat, Jul 15, 2023, 1:58 PM UTC

javajosh wrote: post #10

Checked exceptions are used to make up for Java's inability to return more than one value, plus it's inability to wrap two values without defining a new type. In other words, I think checked exceptions are basically a symptom of a lack of object literal syntax. This is in addition to their status as a "cool language feature" that is a siren song to new, bright programmers looking to spice up their designs. Exceptions…

Exceptions “don’t move the program counter in disjoint ways”, they are part of the “structured gotos”. In fact, it has the same control flow as an early return does, with the handler being locally found in a parent’s (recursively) method body.

Also, the point about multiple return types is pointless — it already has Optional, a proper Return type is completely feasible to implement and use in Java. So is a Pair if tuples are what you mean. Some are just not part of the standard lib by default.

Re: Why checked exceptions failed

#66

Post by dbrueck » Sat, Jul 15, 2023, 1:59 PM UTC

breadwinner wrote: post #14

I have extensive experience in C# as well as Java. It is bizarre to suggest that checked exceptions have failed. It is unchecked exceptions that have failed. It is the biggest flaw of C#, in fact. Why? As an example, I wrote some very good C# code, carefully tested it, made it work flawlessly, then suddenly it started crashing. What happened? Someone made a change in a function I was calling, and it started throwing…

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 a quintessential example of Java's tendency to cause developer fatigue.

Re: Why checked exceptions failed

#67

Post by spreiti » Sat, Jul 15, 2023, 1:59 PM UTC

javajosh wrote: post #10

Checked exceptions are used to make up for Java's inability to return more than one value, plus it's inability to wrap two values without defining a new type. In other words, I think checked exceptions are basically a symptom of a lack of object literal syntax. This is in addition to their status as a "cool language feature" that is a siren song to new, bright programmers looking to spice up their designs. Exceptions…

FYI: With Java 21 (2023/09/19) this is finally possible.

Relevant JEPs:

- 441: Pattern Matching for switch

- 440: Record Patterns

- 409: Sealed Classes

- 395: Records

It is kind of similar to Scalas version of pattern matching with case classes.

Re: Why checked exceptions failed

#68

Post by DougBTX » Sat, Jul 15, 2023, 2:01 PM UTC

cubefox wrote: post #58

Skeime wrote: post #31

Earlier quoted context omitted.

I often run into the opposite problem: There are union types, but I would really like sum types (i.e. tagged unions). The common case is a data structure where I cannot guarantee that the user will not want to use Null as a value in my data structure, but I also need to represent the absence of values myself. With a sum type, my absence would be None and the user’s absence would be Some(None). With union types, I nee…

Something like String|NoAnswer|None doesn't sound too bad to me here...

This isn’t just a problem with custom types, it affects generic iteration types too. With a next() -> Option method, an Iterator can iterate over any type of element.

Re: Why checked exceptions failed

#69

Post by breadwinner » Sat, Jul 15, 2023, 2:03 PM UTC

dbrueck wrote: post #66

breadwinner wrote: post #14

I have extensive experience in C# as well as Java. It is bizarre to suggest that checked exceptions have failed. It is unchecked exceptions that have failed. It is the biggest flaw of C#, in fact. Why? As an example, I wrote some very good C# code, carefully tested it, made it work flawlessly, then suddenly it started crashing. What happened? Someone made a change in a function I was calling, and it started throwing…

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.

Re: Why checked exceptions failed

#70

Post by invalidname » Sat, Jul 15, 2023, 2:03 PM UTC

funnymony wrote: post #61

invalidname wrote: post #53

Earlier quoted context omitted.

Let's say I write an API for handling IO. DB or File or networking or anything really. I get a failure, what do I do? I can throw an exception, but this is important how do I know the user of my API will actually do the cleanup after me. I can't do the cleanup since this is a part of an API not the actual usage of the API. How can I give the user of this API the right set of hint that "you need to pay attention to th…

Any chance you have a code/pseudo code example of this? My naive take on this would be “just use raii/closable”. (But easily and likely, I misunderstood)

Let's say Java had no checked exceptions. I could just write IO code without doing a try since no one is forcing me to check anything.

But let's go further. Let's say I have an API x(). This API accesses my database as part of a larger transaction.

I invoke x() and it fails with an SQLException which is declared. I can revert the transaction or I can choose to retry x(). The checked exception notifies me that there's an important decision I need to make at this point, cleanup is one option but in some cases there are more. Furthermore, cleanup isn't always enough. In a case of an IOException I'd often want to notify the user e.g. if the disk is out of space I want to show an error message somewhere...