Hacker News new | ask | show | jobs
by the_gipsy 1271 days ago
> it gives the impression that it's even possible to define functions that cannot fail

Do you mean that e.g. an out-of-bounds error will panic? If that's the case, you can always access arrays/slices with some checked access, that will return a Result/Option and cannot panic. But it would be a PITA if you couldn't skip that.
1 comments
groestl 1271 days ago
I mean stack overflows or out of memory errors. It might fail one request, but no reason to fail all others.
link
the_gipsy 1271 days ago
That's a very specific case, that could be handled non-trivially.

Usually your HTTP framework will already have this implemented, i.e. a panic in a request handler will be "caught", converted to some 500 response, and should not affect other requests.

link
groestl 1271 days ago
My point is that this is in no way different from any other class of errors, _except_ in those cases where it is. It's practical to assume all errors are handled like this, because this catch all needs to exist anyway. And unless you have _very specific needs_, this can be automated.
link
the_gipsy 1271 days ago
I think conflating these two into one paradigm is worse. The catch-all (exceptions) style is nice only for a few very specific cases, like the request handler example. Everywhere else I want to either bubble up (like exceptions, but Result<> and ? sugar is as good or better), OR I want to handle the error. For the latter case, exceptions are not good at all.
link
groestl 1270 days ago
IMHO, quite often when you're tempted to handle an error, you're either wrong to do so, or in some kind of infrastructure glue code. A request handler, a task executor, a strategy chain, a retry loop, you name it. And this code needs to deal with both classes of errors anyway to be bugfree.
link
the_gipsy 1270 days ago
From those examples, I think only request and task should deal with panics. Things that start threads or processes.

Other points of "catch all errors" don't need that. And then there are a lot of places where you do handle errors, if they are conceptually a Result. I know you can just catch SpecificError, but the ergonomics are just horrible in terms of control flow.

link