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

71–80 of 318 posts

Re: Why checked exceptions failed

#71

Post by funnymony »

throwaway290 wrote: post #33
masklinn wrote: post #7

Earlier quoted context omitted.

It is supported, but does not actually solve anything, you're still limited to whatever checked exceptions the creator of the interface has decided might be valid (it's just that in the original it's "none"). Let's say that the creator of the interface allows IOException, but the backend of my implementation is a database so I have SQLExceptions, same issue. Is the creator of the interface supposed to add every check…

Maybe your SQLException should be caller's IOException? I don't code Java but IMO callers should be hit with errors at the right abstraction level. If caller is using that interface and not your low-level backend functions directly then caller should expect IOException not SQLException. If the interface does not provide exception types for all cases so you are stuck rethrowing your error as a wrong one, and I'd say t…

“bad” might not be the right word. Maybe better “usefulness for current population of developers is very limited”.

Re: Why checked exceptions failed

#72

Post by javajosh »

kaba0 wrote: post #65
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 tu…

>with the handler being locally found in a parent’s (recursively) method body

Yeah, that doesn't sound disjoint /s

Re: Why checked exceptions failed

#73

Post by scarface_74 »

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…

When I’m using grep, it’s usually in the context of shell script. For all intents and purposes it’s a library.

I can choose to handle the error myself or let the shell script crash by having “set -e”.

Grep returns a non zero error code and it’s still up to me to decide how to handle it.

Re: Why checked exceptions failed

#74

Post by tom_ »

croes wrote: post #19
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…

>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 go pop and die immediately, such as a null pointer or divide by zero.

Anyway, I sympathize with this thread's OP, as I've had exactly the same problem with C#. In the end, I came to the conclusion you kind of do often have to catch every exception, because you can't trust the functions you call, and the documented exception lists for framework stuff are not always accurate. Safest is to put each call in its own try...catch block, and do any property accesses outside the try...catch block so you find out about the NullReferenceExceptions.

This is annoyingly verbose though.

It also does assume your setters and getters don't throw anything.

I mostly liked C#, but the exceptions aspect is not good. Similarly, I've generally despised working with Go, but the way it deals with errors is not its worst feature! (You do have to pay attention to the linter output though! It's the same err variable every time, so the compiler's fastidious checks for variable use are always foiled...)

Re: Why checked exceptions failed

#75

Post by invalidname »

scarface_74 wrote: post #73
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…

When I’m using grep, it’s usually in the context of shell script. For all intents and purposes it’s a library. I can choose to handle the error myself or let the shell script crash by having “set -e”. Grep returns a non zero error code and it’s still up to me to decide how to handle it.

That's your point of view. It's up to you. My experience is different and often deals with handles very large projects with serious continuous uptime. When you have dozens of developers committing to a project and using the APIs exiting with an error just isn't an option.

Re: Why checked exceptions failed

#76

Post by scarface_74 »

invalidname wrote: post #75
scarface_74 wrote: post #73

Earlier quoted context omitted.

When I’m using grep, it’s usually in the context of shell script. For all intents and purposes it’s a library. I can choose to handle the error myself or let the shell script crash by having “set -e”. Grep returns a non zero error code and it’s still up to me to decide how to handle it.

That's your point of view. It's up to you. My experience is different and often deals with handles very large projects with serious continuous uptime. When you have dozens of developers committing to a project and using the APIs exiting with an error just isn't an option.

I did say

> I can choose to handle the error myself

Re: Why checked exceptions failed

#77

Post by scarface_74 »

invalidname wrote: post #70
funnymony wrote: post #61

Earlier quoted context omitted.

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…

> 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.

Any decent C# linter will notice that the class exposes (IDisposable) and warn you that you should at least be wrapping it in a “using” block.

Re: Why checked exceptions failed

#78

Post by scarface_74 »

breadwinner wrote: post #59
scarface_74 wrote: post #52

Earlier quoted context omitted.

This is for a library. Whatever the “root” of your code is should have a generic catch all where you do “something”, you don’t want library code (either yours or the system) to decide for the user what should be done with exceptions. As a library writer, you should do something about exceptions that you can and rethrow the ones you can’t,

> Whatever the “root” of your code is should have a generic catch all where you do “something” If your only goal is to avoid crashing the app then you can catch the base Exception class at the root of you code and go home. But consider the scenario that you're writing a very important method, where the functionality of your method is very important. If your method does not do its job, the rocket may crash or the pati…

And then you have a list of catch blocks with the final one being the base.

Re: Why checked exceptions failed

#79

Post by invalidname »

scarface_74 wrote: post #76
invalidname wrote: post #75

Earlier quoted context omitted.

That's your point of view. It's up to you. My experience is different and often deals with handles very large projects with serious continuous uptime. When you have dozens of developers committing to a project and using the APIs exiting with an error just isn't an option.

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 time there's an error would force every library and every part that can fail in my code to know how I plan to handle the error.

Re: Why checked exceptions failed

#80

Post by invalidname »

scarface_74 wrote: post #77
invalidname wrote: post #70

Earlier quoted context omitted.

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…

> 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. Any decent C# linter will notice that the class exposes (IDisposable) and warn you that you should at least be wrapping it in a “using” block.

That's true for Java too. But that's only a part of the problem which is why I gave the second example.

Also, notice that a linter and a compiler error are different. I agree that people *should* always use a good linter and IDE. The reality is sadly far from that.

Post reply on HN