There is a huge difference: the first is an _exception_, which:
- Unwinds the stack to a try/catch or exception handler, making exceptions practically difficult to deal with in concurrent programming.
- If unchecked, can be ignored, silently propagating during stack unwinding.
- If checked, infects the call stack with 'throws' annotations.
The second is a normal return value, with no try/catch needed, handling the error case is mandatory in order to handle the success case, and there is not a separate execution regime occurring whenever an error case is encountered.
I genuinely disagree. There is no difference between a checked exception and a Result.
- In concurrent programming uncaught exceptions won’t leave the future. Both values are available to you just like Results. I also don’t think arguments for concurrent programming are valid though. 99% of all code is single threaded.
- It is checked.
- Result infects the call stack as well.
- handling the error case with a checked exception is also mandatory with handling the success case. There is no separate “execution regime”. What is the difference here:
val a = try {
a();
} catch (b) {
onB();
}
val a = match (a()) {
Success(a) => a
Failure(b) => onB()
}
You definitely just don't know how checked exceptions work. This is not true at all. The compiler will not let you call a(); without handling the exception or checking it up the stack. The same way results work.
- Unwinds the stack to a try/catch or exception handler, making exceptions practically difficult to deal with in concurrent programming.
- If unchecked, can be ignored, silently propagating during stack unwinding.
- If checked, infects the call stack with 'throws' annotations.
The second is a normal return value, with no try/catch needed, handling the error case is mandatory in order to handle the success case, and there is not a separate execution regime occurring whenever an error case is encountered.