Nothing better then having to guess whether the method may throw an exception or not.
You already have to guess. All method calls van throw Runtime exceptions.
Unchecked Java: Say goodbye to checked exceptions
41–50 of 297 posts
Re: Unchecked Java: Say goodbye to checked exceptions
#42Exception based error handling is so bad and unsafe that adopting functional error handling with Either, Try etc as implemented by functional addon libraries for many languages, while not yet common, in time it will become the new default even in OO languages. (just like it's been the default in functional languages for decades) Functional error handling types are much simpler, safer and more powerful. Simpler becaus…
Checked exceptions are exactly analogous of Result/Either types. They are just built into the language with syntactic sugar, automatically unwrap by default (the most common operation), can be handled on as narrow or wide scope as needed (try-catch blocks), does the correct thing by default (bubbling up), and stores stack traces ! In my book, if anything, they are much much better! Unfortunately they don’t have a fla…
> Checked exceptions are exactly analogous of Result/Either types.
No, they aren't.
They are not compositional. You may want to write `f(g())` but there's no way to write the parameter type of `f` to make this work (in Java). That's because checked exceptions are an "effect" that would require extending the Java type system.
Re: Unchecked Java: Say goodbye to checked exceptions
#43Later you detect an error, more expensive it is to fix it.
Re: Unchecked Java: Say goodbye to checked exceptions
#44Exception based error handling is so bad and unsafe that adopting functional error handling with Either, Try etc as implemented by functional addon libraries for many languages, while not yet common, in time it will become the new default even in OO languages. (just like it's been the default in functional languages for decades) Functional error handling types are much simpler, safer and more powerful. Simpler becaus…
> Safer because unlike exceptions, they force callers to handle all potential outcomes, but no more. Which is bad. In 99% of cases I have no specific error handling for the given problem. Just let the process crash or be handled by application server / framework. Representing these kinds of error conditions in the code which I have no interest in handling is just noise.
Situations vary a lot. In general there's no guarantee that a far outer scope is going to know how to deal with errors from deep inside some nested calls except for some very general logic, like failing a whole operation.
Re: Unchecked Java: Say goodbye to checked exceptions
#45Earlier quoted context omitted.
Exception based error handling is unsafe when they are unchecked exceptions. Checked exceptions however are as safe as Either, Try, Monads, Applicatives or whatever. You are forced to declare them in your method signature, the caller is forced to either handle them or rethrow them + declare them as well. And I guess this is precisely why so many developers hate them; they don't like the extra work they have to do to…
Ultimately, core language features that make things ergonomic enough for lazy developers to get it right will result in better software. And ones that are so unergonomic that only industrious developers will get them right will result in worse software. Modern languages allow these to be zero cost abstractions so there is little tradeoff.
I have been coding in Scala/ Haskell for the last 10 years, before that 15 years in Java. What I'm seeing is that there are as many lazy developers in FP as there are in Java, maybe even more.
And despite all the nice safeguards that FP provides, there are still plenty of ways for lazy devs to work around them.
For instance the IO monad, which is used everywhere Scala/Cats. It can contain a result or an error. If you don't feel like checking for an error after you called some method, you can just pass it up and return the IO from your method. Does that sound familiar? It behaves just like a checked exception, the only difference is that methods don't need to declare any error or exception in their IO signature.
Re: Unchecked Java: Say goodbye to checked exceptions
#46Reading through the comments, I realize this may be a minority view - but I like coding for the happy path and letting exceptional states crash. I find languages like go a bit harder to parse quickly because I always have to "unwrap" the happy path from all of the mixed in error handling.
I'm sure I'd get used to it eventually, but I like that unchecked exceptions in Java are now an option!
Re: Unchecked Java: Say goodbye to checked exceptions
#47This dependency removes one of the best features of Java, which make others think about what happens if things go wrong.
Re: Unchecked Java: Say goodbye to checked exceptions
#48Most other languages agree that checked exceptions are not good by not having them.
As for alternatives, Try/Result and similar monads have decent adoption even in Java, but personally I quite like the Kotlin philosophy [1] to not have generic error containers and either use runtime exceptions for errors that cannot be reasonably handled by the caller and encapsulate failures in the return type if they can.
[1] https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/...
Re: Unchecked Java: Say goodbye to checked exceptions
#49Earlier quoted context omitted.
Checked exceptions are exactly analogous of Result/Either types. They are just built into the language with syntactic sugar, automatically unwrap by default (the most common operation), can be handled on as narrow or wide scope as needed (try-catch blocks), does the correct thing by default (bubbling up), and stores stack traces ! In my book, if anything, they are much much better! Unfortunately they don’t have a fla…
> Checked exceptions are exactly analogous of Result/Either types. No, they aren't. They are not compositional. You may want to write `f(g())` but there's no way to write the parameter type of `f` to make this work (in Java). That's because checked exceptions are an "effect" that would require extending the Java type system.
Read my last paragraph.
Re: Unchecked Java: Say goodbye to checked exceptions
#50Reading through the comments, I realize this may be a minority view - but I like coding for the happy path and letting exceptional states crash. I find languages like go a bit harder to parse quickly because I always have to "unwrap" the happy path from all of the mixed in error handling. I'm sure I'd get used to it eventually, but I like that unchecked exceptions in Java are now an option!
I'm fine with doing this on purpose, but without a system like checked exceptions, you do it without even really realizing you're doing it. Checked exceptions point out the errors and then let you decide whether it's something you should handle or let it crash. It makes for more stable software.