News for hackers. Stuff that matters.
Re:Bad programming ideas that only become apparent after years by rualca on Sunday December 27, 2020 @06:45PM (#25555216)
They really aren't. Exceptions handle exceptional events that potentially lead to a shutdown, while the Result monad only reports.... Results.

I mean, not finding a record in a database is not an error, nor is getting a response to a HTTP request with status code 3xx or a 404 or a 409.

Re:Bad programming ideas that only become apparent after years by joshuamorton on Sunday December 27, 2020 @09:36PM (#25556194)
> I mean, not finding a record in a database is not an error, nor is getting a response to a HTTP request with status code 3xx or a 404 or a 409.

But in some languages, exceptions would be used to handle these cases. Admittedly, those languages are usually higher level than C/C++ (but both Java and Python would probably find it common to handle a 3xx or a 404 or a missing row with an exception)

At a high level, I think the important thing is that funct() -> Result<T> and func() -> T that may throw/raise an exception are basically equivalent. Result may require slightly more explicitness at (at least) one call site, but ultimately both allow you to return a T, or report some non-T result, in a structured way. The only difference is that exceptions force you to handle the result explicitly (although that may just mean a single call to value! or VALUE_OR_DIE, or whatever the "get the T or segfault/panic" method is). In this way, I really do think checked exceptions are highly analogous to Result types.

Implementations may have different performance tradeoffs, but those aren't implicit in the choice of exception vs. result.