4 ms·

Exception handling and closing resources keep to be a major pain in the ass. Worst, the lambdas do not fit well with checked exceptions and the standard library

by chopin 7y ago

Exception handling and closing resources keep to be a major pain in the ass. Worst, the lambdas do not fit well with checked exceptions and the standard library is full of them. Another major pain are closing methods which throw checked exceptions themselves. This makes wrapping this into a decent lambda painful. I'd have preferred much lambdas just exposing checked exceptions they experience inside. I can't imagine why the compiler shouldn't be able to do this. Maybe one would have to come up with a fancy definition of functional interfaces (although I think this could be tackled with an annotation if the language doesn't provide this for lack of another keyword a la "throwsall").

Quekid5 7y ago
Checked exceptions should just be removed entirely from Java. It's a completely failed experiment. If you really want something like checked exceptions then (anonymous) intersection types or row polymorphism would be much better approaches than the adhoc thing Java does... but I suspect that that wouldn't well with the variance system in Java. (Thankfully it's only the Java compiler itself which imposes checked-ness, so other languages on the JVM thankfully don't have to deal with the insanity.)
- watwut 7y ago
  There is nothing failed about checked exception. It is better then finding out about runtime exceptions as they happen.
  - nine_k 7y ago
    If an exception should be expected and handled, it's not an exceptional case, it's a part of the function's signature. The lack of sum types and pattern matching notwithstanding, such a signature can be implemented reasonably in Java.
  - chopin 7y ago
    I am not against checked exceptions per se. Their excessive use of them in the standard library and especially the inability of lambdas in handling them are a problem imho. Take the stream close methods: There is absolutely no use in having those throwing a checked exception because there is nothing you can do. If closing is not possible you have problems with the underlying OS. That would rather warrant an error instead of an exception.
  - Quekid5 7y ago
    Yes there is. I have enough material enough on this for several blog posts, but I won't belabor the point. One, why do you think almost all non-standard java libraries almost exclusively use exceptions derived from RuntimeException? Two, I encourage you to look up guava's Throwables utility class and consider why it is even a thing. Just for a single example: Methods with no throws clause cannot throw exceptions, so you must wrap in a RuntimeException... but that means that outer catch clauses which match on the checked exception WILL NOT MATCH on the RTExc-wrapped-exception. This is broken as all hell.
- peterashford 7y ago
  I like checked exceptions. It's nice getting a reminder about issues I need to handle and its trivial to just get everything to pass on exceptions if that's the disposition I choose for my code base
  - Quekid5 7y ago
    It's not trivial if you're forced to conform to an interface which has a narrower "throws" clause than what you need. It's an issue of contravariance vs. covariance. Implementations of an interface/superclass are typically more concrete, and so they need to be able to throw more more types of exceptions... but throws clauses work in the opposite way: You're only allowed to narrow them, not expand them in subclasses/implementations-of-interfaces. It's simply broken. EDIT: Just to add: What happens in practice is that either - you just give up and declare "throws Exception" on the interface (in which case: why bother? You might as well just remove checked exceptions at that point), or - you wrap checked exceptions in RuntimeException, but now you have a new problem: Consider a method that calls methods f and g where f declares a "throws Foo", but g doesn't declare any exceptions[0], but may throw Foo's at runtime by wrapping. Now you're totally screwed, because a "catch Foo" will not match exceptions from g. The Guava people have written a whole Throwables utility class to help with this, but using that consistently requires discipline that no team can handle, and it only handles a small subset of the problem. This is just a small sample of the problems with checked exceptions in Java. [0] g may be used in contexts where it's not "allowed" to declare checked exceptions in a throws clause, e.g. lambdas or just higher-order functions in general.

by chopin 7y ago

Quekid5 7y ago

Checked exceptions should just be removed entirely from Java. It's a completely failed experiment. If you really want something like checked exceptions then (anonymous) intersection types or row polymorphism would be much better approaches than the adhoc thing Java does... but I suspect that that wouldn't well with the variance system in Java. (Thankfully it's only the Java compiler itself which imposes checked-ness, so other languages on the JVM thankfully don't have to deal with the insanity.)

watwut 7y ago
There is nothing failed about checked exception. It is better then finding out about runtime exceptions as they happen.
- nine_k 7y ago
  If an exception should be expected and handled, it's not an exceptional case, it's a part of the function's signature. The lack of sum types and pattern matching notwithstanding, such a signature can be implemented reasonably in Java.
- chopin 7y ago
  I am not against checked exceptions per se. Their excessive use of them in the standard library and especially the inability of lambdas in handling them are a problem imho. Take the stream close methods: There is absolutely no use in having those throwing a checked exception because there is nothing you can do. If closing is not possible you have problems with the underlying OS. That would rather warrant an error instead of an exception.
- Quekid5 7y ago
  Yes there is. I have enough material enough on this for several blog posts, but I won't belabor the point. One, why do you think almost all non-standard java libraries almost exclusively use exceptions derived from RuntimeException? Two, I encourage you to look up guava's Throwables utility class and consider why it is even a thing. Just for a single example: Methods with no throws clause cannot throw exceptions, so you must wrap in a RuntimeException... but that means that outer catch clauses which match on the checked exception WILL NOT MATCH on the RTExc-wrapped-exception. This is broken as all hell.
peterashford 7y ago
I like checked exceptions. It's nice getting a reminder about issues I need to handle and its trivial to just get everything to pass on exceptions if that's the disposition I choose for my code base
- Quekid5 7y ago
  It's not trivial if you're forced to conform to an interface which has a narrower "throws" clause than what you need. It's an issue of contravariance vs. covariance. Implementations of an interface/superclass are typically more concrete, and so they need to be able to throw more more types of exceptions... but throws clauses work in the opposite way: You're only allowed to narrow them, not expand them in subclasses/implementations-of-interfaces. It's simply broken. EDIT: Just to add: What happens in practice is that either - you just give up and declare "throws Exception" on the interface (in which case: why bother? You might as well just remove checked exceptions at that point), or - you wrap checked exceptions in RuntimeException, but now you have a new problem: Consider a method that calls methods f and g where f declares a "throws Foo", but g doesn't declare any exceptions[0], but may throw Foo's at runtime by wrapping. Now you're totally screwed, because a "catch Foo" will not match exceptions from g. The Guava people have written a whole Throwables utility class to help with this, but using that consistently requires discipline that no team can handle, and it only handles a small subset of the problem. This is just a small sample of the problems with checked exceptions in Java. [0] g may be used in contexts where it's not "allowed" to declare checked exceptions in a throws clause, e.g. lambdas or just higher-order functions in general.