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

91–100 of 318 posts

Re: Why checked exceptions failed

#91

Post by tom_ »

EricRiese wrote: post #81
tom_ wrote: post #74

Earlier quoted context omitted.

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.

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 name encoding is valid, and another where it is not. And so on. It makes no sense, in my view, for one case to be handled with one language mechanism and the other case to be handled with another.

By comparison, there is (or so I claim!) no valid path where a null pointer is dereferenced, or where a value is divided by zero. So I will accept the requirement for some other mechanism for dealing with these - though by the time the code is released to the wild, I would hope that all such occurrences would have been eliminated.

Re: Why checked exceptions failed

#92

Post by Kamq »

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…

> Someone made a change in a function I was calling, and it started throwing a new exception. This would have caused a compile error in Java, not a crash.

I call BS here. I've worked in a few Java projects, and in every single one, the people changing the method in question would have thrown RuntimeException to stop the compile errors.

If RuntimeException was checked, you might have a point, but given that there's a class of unchecked exceptions, you're relying on discipline instead of the compiler anyways.

Re: Why checked exceptions failed

#93

Post by breadwinner »

Kamq wrote: post #92
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…

> Someone made a change in a function I was calling, and it started throwing a new exception. This would have caused a compile error in Java, not a crash. I call BS here. I've worked in a few Java projects, and in every single one, the people changing the method in question would have thrown RuntimeException to stop the compile errors. If RuntimeException was checked, you might have a point, but given that there's a…

You need to help train your coworkers to write better code :) Point this thread out to them.

Seriously, Java doesn't force bad programmers to write good code. It just enables good programmers to write good code.

Re: Why checked exceptions failed

#94

Post by lostmsu »

wiseowise wrote: post #87
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.

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”

You could say Rust error handling is more like checked than unchecked exceptions.

Re: Why checked exceptions failed

#95

Post by wiseowise »

lostmsu wrote: post #94
wiseowise wrote: post #87

Earlier quoted context omitted.

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”

You could say Rust error handling is more like checked than unchecked exceptions.

It is, that’s the whole point.

Re: Why checked exceptions failed

#96

Post by cubefox »

DougBTX wrote: post #68
cubefox wrote: post #58

Earlier quoted context omitted.

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.

Yeah, but there could be a type T for "any type" additional to union types, basically like TRUE in Boolean logic. (Theoretically you could also have F for "no type", intersection types (AND), negation types (not Foo), and any logical complex of those.)

Re: Why checked exceptions failed

#97

Post by specialist »

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…

> infuriating that try{} opens up a new lexical scope

This slays me.

The try, catch, and finally blocks should be just one lexical scope.

Re: Why checked exceptions failed

#98

Post by Kamq »

breadwinner wrote: post #93
Kamq wrote: post #92

Earlier quoted context omitted.

> Someone made a change in a function I was calling, and it started throwing a new exception. This would have caused a compile error in Java, not a crash. I call BS here. I've worked in a few Java projects, and in every single one, the people changing the method in question would have thrown RuntimeException to stop the compile errors. If RuntimeException was checked, you might have a point, but given that there's a…

You need to help train your coworkers to write better code :) Point this thread out to them. Seriously, Java doesn't force bad programmers to write good code. It just enables good programmers to write good code.

I will acknowledge that this wasn't the best code (or the best programmers).

I will also cede the point that you can write good code in Java.

But my point was that Java wouldn't have enforced the situation to be a compile error, not that you can't write good code in Java. I maintain this point, and I think it's true for the average java project.

If you're getting these benefits from Java, it's the intersection of Java and your team's or your organization's culture, not purely from Java. It's possible for you to gain this benefit and for checked exceptions to have still failed out in the wider world of the average Java project.

Re: Why checked exceptions failed

#99

Post by xen0 »

breadwinner wrote: post #93
Kamq wrote: post #92

Earlier quoted context omitted.

> Someone made a change in a function I was calling, and it started throwing a new exception. This would have caused a compile error in Java, not a crash. I call BS here. I've worked in a few Java projects, and in every single one, the people changing the method in question would have thrown RuntimeException to stop the compile errors. If RuntimeException was checked, you might have a point, but given that there's a…

You need to help train your coworkers to write better code :) Point this thread out to them. Seriously, Java doesn't force bad programmers to write good code. It just enables good programmers to write good code.

And a lack of checked exceptions means good programmers can't write good code? So good code may only be written in Java?

No... I don't think so.

Checked Exceptions are at best, just a 'hey, are you sure that's right thing to do here?' and at worst, an additional source of rigidity in your code that blows up the scale of a minor change.

Re: Why checked exceptions failed

#100

Post by kaba0 »

javajosh wrote: post #72
kaba0 wrote: post #65

Earlier quoted context omitted.

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

That’s the exact same thing as if you had a function call as the last statement in a functional call as a last statement, etc. Literally just popping off stackframes.
Post reply on HN