Why checked exceptions failed
borretti.me
Why checked exceptions failed
1–10 of 318 posts
Re: Why checked exceptions failed
#2I am surprised an even more obvious interface definition of
public interface ExampleInterface {
void foo() throws IOException, AnotherException;
}
That would solve a lot of use cases if inheritance is respected.
Re: Why checked exceptions failed
#3"Nobody uses [checked exceptions" in Java, this casually claims.
Oh dear. I have a slew of current counter examples on my machine, in GitHub, etc.
Either carelessly untrue or else annoying hypebole.
Made the rest very hard for me to read.
Re: Why checked exceptions failed
#4I am surprised an even more obvious interface definition of public interface ExampleInterface { void foo() throws IOException, AnotherException; } was not covered: is this also not supported? That would solve a lot of use cases if inheritance is respected.
This is indeed the supported way to do it.
Re: Why checked exceptions failed
#5This is a very old topic. Insights from Anders Hejlsberg:
https://www.artima.com/articles/the-trouble-with-checked-exc...
Re: Why checked exceptions failed
#6> Can I specify that implementations of foo can throw no, some, or all exceptions?
just because theres the possibility of a throw in the signature, does not mean it has to be done in a concrete implementation, and if implementations are really to be exchangable, it has to be handled in case implementation changes.
> What would it even mean to write something like throws *?
Roughly similar to "throws Exception" or "throws Throwable" - that it may throw whatever you have under the sun?
> Concretely, checked exceptions in Java failed because Java lacks “throwingness polymorphism”, if you will.
it does allow for extending exceptions, so an interface can define some exceptions that are basic, and implementations can then choose to extend those to provide MORE detail if needed.
> Was Java wrong to add checked exceptions? No. They took a risk and it didn’t pay off.
Uhm.... Im gonna go ahead and use some other opinion on this
Re: Why checked exceptions failed
#7I am surprised an even more obvious interface definition of public interface ExampleInterface { void foo() throws IOException, AnotherException; } was not covered: is this also not supported? That would solve a lot of use cases if inheritance is respected.
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 checked exception in the standard library? Ignoring that this still isn't all of them, then the caller is hosed because they have to handle (or rethrow) every single one of them which is no better. So they probably go "fuck it" and just handle / rethrow Exception. At which point you can just do that on the interface, and it's not helping anyone, and you're better off just not saying anything.
Checked exceptions simply don't mesh with the language: because the language provides limited to no way to abstract over them they're an issue every time you're trying to be generic over anything, the only situation in which they kinda sorta work is if the entire callchain is concrete, which not only is very limiting but it's very much not idiomatic.
Re: Why checked exceptions failed
#8I am surprised an even more obvious interface definition of public interface ExampleInterface { void foo() throws IOException, AnotherException; } was not covered: is this also not supported? That would solve a lot of use cases if inheritance is respected.
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 possible exception on "foo() " when defining the interface, and then handle every possible exception in any code that uses "ExampleInterface".
At that point, it would be better to not annotate exception information at all.
Re: Why checked exceptions failed
#9The issue with all exceptions, and error handling in general, is that only very rarely is there actually recourse for an error. For instance, in an HTTP request handler, the vast majority of errors will end up as something like a 500. Checked exceptions are annoying because they make you explicitly handle an error when you likely already have a handler in place to handle all exceptions, checked or otherwise.
Re: Why checked exceptions failed
#10Checked 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 are in general problematic (they move the program counter in a disjoint way - "non-local change of control" I think it's called) so it makes this particular siren song doubly deadly.
It would probably be handy if someone wrote a pamphlet on "Refactoring Exceptions" to give teams the confidence to refactor exceptions out of their code. I'll offer $20 to Martin Fowler to write such a thing.