News for hackers. Stuff that matters.
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.

There are no comments on this comment yet.