Checked exceptions don't cause people to write good error handling code, they just cause a crisis for no good reason when you are writing code that people will answer with some lame answer like
in most languages what you can do is build a framework that controls execution in such a way that (in the context of a stream of work units) it can "separate the code that actually recovers from an error from the code that decides how to recover" as that article says as best you can.
People only handle checked exceptions that way because Java the language hasn’t given them the tools to deal with them properly (Swift does a good job at this) and historically people would check exceptions from their downstream function calls that they couldn’t handle rather than unchecking them.
Checked errors are good and are so important to have program correctness, but you need a way to easily escape them when necessary. Rust and Swift have both have realized this. Rust provides ? and Swift has try!, Java needs the same.
> Look at the JDK 8 streams library of an example of a library that (a) is awkward as hell because you can't
> stream.map(this::someMethodThatMightThrowAndException)
My impression (based on two projects) is that Scala is snake oil.
(1) We were trying to parallelize an easily parallelizable task in Scala. Except it would only use a fraction of the CPUs available and didn't always give the right answer. In three days I was no closer to getting the Scala solution using all cores, I was able to do it in three minutes with Java Executor.
(2) I saw a somewhat larger code base that implemented a data processing pipeline. I was told by the eng manager that (a) we do code reviews and (b) we use monads for error handling. I guess we did, except it was the monad equivalent of
try { something() } catch(SomeException x) {}
most of the time which, once more, fits pattern of people writing exception handling code to silence the compiler.
In principle something like monads could let you implement more complex error handling strategies (like Lisp) but so long as "a monad is a like a burrito and a computation is like a graph", monads will be underpowered. Note you can use polymorphism for handling errors in Java too, for instance
interface FunctionThatThrows<In,Out,X> {
Out applies(In arg) throws X;
}
JDK8 streams could have done better with the tools it had.
A bad programmer can write bad code no matter the language. Java lets you write good code if you're a good programmer. C# on the other hand makes you write bad code even if you're a good programmer. Why? Because you have no idea what exceptions are possible, and whether the handlers you have are even needed anymore.
I participate in a couple of Java communities and checked exceptions are considered a huge anti-pattern in both. Please don't mistake preference for objective reality.
That's not a valid argument. Lots of people believed the earth is flat but we now know that's not true. Did you read the article? Explain why it is wrong.
And yet using checked Results seems to be the pattern that most programming communities are heralding. Java has just made checked errors awkward to deal with.
This is what happens when a wrong narrative takes root and you don't nip it in the bud. Many programming communities have embraced the wrong narrative, and if you approach those communities and challenge them, all they can respond with is, "everyone else says so, so you must be wrong".
https://gen5.info/q/2008/07/31/stop-catching-exceptions/
Checked exceptions don't cause people to write good error handling code, they just cause a crisis for no good reason when you are writing code that people will answer with some lame answer like
or or when you really should be doing something like and finally deal with the exception at the end of the "work unit", seehttps://gen5.info/q/2008/08/27/what-do-you-do-when-youve-cau...
Look at the JDK 8 streams library of an example of a library that (a) is awkward as hell because you can't
but (b) still handles errors improperly. Some versions of Lisp have a much better approach described herehttps://gigamonkeys.com/book/beyond-exception-handling-condi...
in most languages what you can do is build a framework that controls execution in such a way that (in the context of a stream of work units) it can "separate the code that actually recovers from an error from the code that decides how to recover" as that article says as best you can.