> Exception 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)
I honestly doubt this. Especially since Java is investing further into exceptions with this JEP.
> Functional error handling types are much simpler, safer and more powerful. Simpler because they don't rely on dedicated syntax- they're just regular objects no different to any other object.
Who cares? Languages can build the syntax, make it easier, and make it consistent rather than having specific dialects that comes from libraries. Either, Try, Result which one do I choose? This is better delegated to the language rather than DSLs.
> Safer because unlike exceptions, they force callers to handle all potential outcomes, but no more. (no risk of ignoring errors and no risk of catching a higher level of error than desired, ubiquitous bugs in exception based error handling)
> Safer because unlike exceptions, they force callers to handle all potential outcomes, but no more. (no risk of ignoring errors and no risk of catching a higher level of error than desired, ubiquitous bugs in exception based error handling)
I'm not sure they are safer at all. Either, Try, and Result don't force you to check the errors, they all offer escape hatches. How many times has there been rust code that just calls `.unwrap` because the author doesn't care or thinks the error can't occur. I've seen tons of Kotlin code that uses !! to get out of null checking because the author doesn't believe something could be null and can't handle it actually being null.
I honestly doubt this. Especially since Java is investing further into exceptions with this JEP.
> Functional error handling types are much simpler, safer and more powerful. Simpler because they don't rely on dedicated syntax- they're just regular objects no different to any other object.
Who cares? Languages can build the syntax, make it easier, and make it consistent rather than having specific dialects that comes from libraries. Either, Try, Result which one do I choose? This is better delegated to the language rather than DSLs.
> Safer because unlike exceptions, they force callers to handle all potential outcomes, but no more. (no risk of ignoring errors and no risk of catching a higher level of error than desired, ubiquitous bugs in exception based error handling)
> Safer because unlike exceptions, they force callers to handle all potential outcomes, but no more. (no risk of ignoring errors and no risk of catching a higher level of error than desired, ubiquitous bugs in exception based error handling)
I'm not sure they are safer at all. Either, Try, and Result don't force you to check the errors, they all offer escape hatches. How many times has there been rust code that just calls `.unwrap` because the author doesn't care or thinks the error can't occur. I've seen tons of Kotlin code that uses !! to get out of null checking because the author doesn't believe something could be null and can't handle it actually being null.