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

151–160 of 318 posts

Re: Why checked exceptions failed

#151

Post by saurik »

tom_ wrote: post #91
EricRiese wrote: post #81

Earlier quoted context omitted.

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

No value judgement here, I don't think, at least not from me (though of course my values inform every opinion I have, including this one). I simply claim that every path is equivalent, and all must be considered. I claim there is no so-called "happy path" - a term I reject - nor do "errors" really exist. There is one case where the socket send succeeded, and another where it failed. There is one case where the file n…

The correct behavior for not just the vast majority of these conditions but virtually all of them is the same: propagate the error. You aren't going to sit around and try to "recover" from failing to send a packet or encode a filename: you just report it to higher level code. There might be something you can do at a higher level--such as reconnecting or using a different server from a load balancing list--but at that point the exact reason is irrelevant (and yet should be maintained in case the higher level code needs to inform the user in either a dialog or a log file): failure is, virtually all of the time, boolean in nature and a non-local phenomenon.

Re: Why checked exceptions failed

#152

Post by im3w1l »

mkleczek wrote: post #148
im3w1l wrote: post #143

Earlier quoted context omitted.

I think the issue with this pattern is that either we don't care about went wrong, we want to treat all errors the same way, and then having n catch clauses is overkill. Or we do care about went wrong, and in that case the exception type is not enough to identify the issue, as often multiple lines in the try block will throw the same exception type.

Yes - that's one of the issues with structured exception handling. Relying only on exception type itself is not enough as information is lost (ie. the actual source of exception)

Crazy idea: Maybe it would be helpful if we could label operations, and catch by either label or type or (label, type). The we could centralize error handling without losing anything.

Re: Why checked exceptions failed

#153

Post by nemetroid »

specialist wrote: post #133
xen0 wrote: post #106

Earlier quoted context omitted.

I don't think that helps? If, as is kind of the point of RAII, your constructors do some initialization and that initialization may fail, then: If you have a single object that may fail to construct then maintaining it in scope for the catch block doesn't make sense; it's not initialized. If you have several, then you still can't maintain them in scope, because you don't know which ones are actually valid. Yes there…

I misspoke. Ignoring the syntax for a moment, I want scoping to behave like this pseudo-code. So that the catch and finally blocks are lexically nested within the parent try block. try { OutputStream out = ... ... // Must be at end of try block catch ExceptionA, Exception B { ... } catch Exception C { ... } finally { ... } } // end of try Maybe even allow catch and finally to allow single expression in addition to bl…

If constructing "out" fails but one of the catch-blocks tries to use "out", what should happen?

Re: Why checked exceptions failed

#154

Post by dimgl »

crabbone wrote: post #136
invalidname wrote: post #12

My opinion is the exact opposite see https://debugagent.com/everything-bad-in-java-is-good-for-yo... Checked exceptions are unpopular since no one likes responsibility. But they are great when used right. Calls that must have proper cleanup after them e.g. SQL, IO are checked. The fact that this must be communicated via interfaces is hugely important. There are "weird" problems such as stream close() throwing a check…

This comes from a misunderstanding of the reason why exceptions where designed they way they were. The whole point of exceptions bubbling up w/o having to write support code to deal with passing exceptions further is to make it so that the purpose of the function is clear to the reader. Go's exceptions have the same unfortunate property as Java's checked exception. And that's what makes Go's code atrocious. Every oth…

> Go's exceptions have the same unfortunate property as Java's checked exception.

Wait what? Here's where you lost me. You don't "throw" errors in Golang. Instead it's common practice for functions to return multiple values, one of which can be an error. Errors are just structs that implement the Error interface.

The language (and the compiler by extension) doesn't make you explicitly handle errors. On the contrary: you can choose to ignore errors altogether.

On the other hand, a checked exception in Java is one that MUST be either caught or declared in the method in which it is thrown. Code that fails to do this won't compile. You're completely wrong here.

Re: Why checked exceptions failed

#155

Post by osigurdson »

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…

Exceptions are great when they don’t need to be caught. Otherwise they are a pain.

Re: Why checked exceptions failed

#156

Post by he0001 »

masklinn wrote: post #85
he0001 wrote: post #48

Earlier quoted context omitted.

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.

Yeah, and he’s wrong about it.

Re: Why checked exceptions failed

#157

Post by throwawaymaths »

invalidname wrote: post #12

My opinion is the exact opposite see https://debugagent.com/everything-bad-in-java-is-good-for-yo... Checked exceptions are unpopular since no one likes responsibility. But they are great when used right. Calls that must have proper cleanup after them e.g. SQL, IO are checked. The fact that this must be communicated via interfaces is hugely important. There are "weird" problems such as stream close() throwing a check…

Not exceptions, but zig has explicit error return types, and it works great. Especially since you can also just "tell the compiler to figure it out". There are a few cases where the compiler can't figure it out, but in those cases you grudgingly annotate the error types and it's done.

Re: Why checked exceptions failed

#158

Post by necovek »

masklinn wrote: post #45
maratc wrote: post #36

Earlier quoted context omitted.

> 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. The creator of the interface should decide on a generic exception type: public interface UniversalStorageInterface { void store() throws StorageException; } Then, in the present, the FileStorage can define (and throw) a FileStorageException (inherits from StorageExc…

So now whoever creates the interface needs to define an exception type per method, and whoever implements the interface needs to define a subclass of that per method and catch-and-wrap every exception their callee raises. You better add some serious tooling built into the language to facilitate this, because from experience ain't no way anyone's going to bother with this if they have to handroll it, even with IDE cod…

Whether you do it with exceptions hierarchy or error types or something else, it's pretty much the same thing: you either handle all the errors or not (or anything in between).

How do you solve that error complexity with any other approach and how is that different using any other syntax sugar?

The only thing I dislike about exceptions is that they are ignored by default allowing people to all too easily write code with no error checking.

Re: Why checked exceptions failed

#159

Post by vips7L »

crabbone wrote: post #127
breadwinner wrote: post #69

Earlier quoted context omitted.

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.

You are very confused... "strong" in strong typing doesn't mean you have to write much or at all. Actually, it doesn't mean anything really. But, let's say, Haskell is probably at least as "strongly typed" as Java -- at least that's how most people understand that wording. And you don't have to write types in Haskell at all. It will be a nightmare (as if Haskell can be anything else, but even by the very low Haskell…

> Until very recently, Java was just tedious, repetitive, high-entropy language, where you had to write everything multiple times.

More than half a decade ago.

Re: Why checked exceptions failed

#160

Post by mostlylurks »

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, which means you can't construct something, check for errors and move on

You technically can with a small workaround (demonstrated below), though I personally wouldn't use this approach.

    void foo() {
      auto value = [] {
        try {
          return Foo();
        } catch (...) {
          // Something here
        }
      }();
      value.do_something();
    }
Post reply on HN