4 ms·

> Java has a worst model of exception mixing weird typechecking rules + error handling not forcing to recover the exception. Unless you have a specific complai

> Java has a worst model of exception mixing weird typechecking rules + error handling not forcing to recover the exception. Unless you have a specific complaint about Java's model (which I'd love to read), I strongly suspect that your beef is with a few standard Java library functions misusing checked exceptions than a statement against exceptions in general. The combination of runtime and checked exceptions offers the most complete solution to the difficult problem of handling errors, with the compiler guaranteeing that error paths are always handled.

loopz 7y ago
Sounds nice, and of course it is possible to build solutions with exceptions that do recover all errors elegantly and cleanly. However, the correct judge on this would be your own users. Given enough care, the discussion becomes rather philosophical. Though, having to confront errors through the callstack makes one review where handling would be most prudent, in real-life the time-pressures are just too strong making such efforts largely unrewarded.
int_19h 7y ago
The big problem with Java's model is that exceptions aren't part of the type system: they're that whole separate thing that is applied to methods, but it's not a part of that method's type in any meaningful sense. This means that it's impossible to write a higher-order function along the lines of "map" or "filter" that would properly propagate exceptions, because there's no way to capture the throws-clause of the predicate and surface it on the HOF itself.
- hota_mazi 7y ago
  `> The big problem with Java's model is that exceptions aren't part of the type system They are. To the extent that the checked exceptions that a method can throw are part of the method signature (as all error cases should). I have no idea what you mean by "exceptions aren't part of the type system".

loopz 7y ago

Sounds nice, and of course it is possible to build solutions with exceptions that do recover all errors elegantly and cleanly. However, the correct judge on this would be your own users. Given enough care, the discussion becomes rather philosophical. Though, having to confront errors through the callstack makes one review where handling would be most prudent, in real-life the time-pressures are just too strong making such efforts largely unrewarded.

int_19h 7y ago

The big problem with Java's model is that exceptions aren't part of the type system: they're that whole separate thing that is applied to methods, but it's not a part of that method's type in any meaningful sense. This means that it's impossible to write a higher-order function along the lines of "map" or "filter" that would properly propagate exceptions, because there's no way to capture the throws-clause of the predicate and surface it on the HOF itself.

hota_mazi 7y ago
`> The big problem with Java's model is that exceptions aren't part of the type system They are. To the extent that the checked exceptions that a method can throw are part of the method signature (as all error cases should). I have no idea what you mean by "exceptions aren't part of the type system".