3 ms·

That's the way, but I find it quite painful at time. Adding a new error variant to a function means I now have to travel up the hierarchy of its callers to hand

That's the way, but I find it quite painful at time. Adding a new error variant to a function means I now have to travel up the hierarchy of its callers to handle it or add it to their error set as well.

mdaniel 1y ago
Sometimes that error was being smuggled in another broader error to begin with, so if the caller is having to go spelunking into the .description (or .message) to know, that's a very serious problem. The distinction I make is: if the caller knew about this new type of error, what would they do differently?
slau 1y ago
This shouldn’t happen unless you’re actively refactoring the function and introducing new error paths. Therefore, it is to be expected that the cake hierarchy would be affected. You would most likely have had to navigate up and down the caller chain regardless of how you scope errors. At least this way the compiler tells you when you forgot to handle a new error case, and where.
layer8 1y ago
This is eerily reminiscent of the discussions about Java’s checked exceptions circa 25 years ago.
- mananaysiempre 1y ago
  The difference is that Java does not have polymorphism for exception sets (I think? certainly it didn’t for anything back then), so you couldn’t even type e.g. a callback-invoking function properly. Otherwise, yes, as well as the discussions about monad transformers in Haskell from 15 years ago. Effects are effects are effects.
  - layer8 1y ago
    You can abstract over a finite set of exception types in Java with generics, but it doesn’t always work well for n > 1 and is a bit boilerplate-y. The discussions I was referring to predate generics, however.
Expurple 1y ago
That's only the case when your per-function error sets are "flat" (directly contain "leaf" errors from many layers below). You can avoid this issue if you deeply nest the error types (wrap on every level). It you change an error that's not deeply-matched anywhere, you only need to update the direct callers. But "deep" errors have some tradeoffs [1] too [1]: https://news.ycombinator.com/item?id=44420061 https://news.ycombinator.com/item?id=44420061

mdaniel 1y ago

Sometimes that error was being smuggled in another broader error to begin with, so if the caller is having to go spelunking into the .description (or .message) to know, that's a very serious problem. The distinction I make is: if the caller knew about this new type of error, what would they do differently?

slau 1y ago

This shouldn’t happen unless you’re actively refactoring the function and introducing new error paths. Therefore, it is to be expected that the cake hierarchy would be affected. You would most likely have had to navigate up and down the caller chain regardless of how you scope errors. At least this way the compiler tells you when you forgot to handle a new error case, and where.

layer8 1y ago

This is eerily reminiscent of the discussions about Java’s checked exceptions circa 25 years ago.

mananaysiempre 1y ago
The difference is that Java does not have polymorphism for exception sets (I think? certainly it didn’t for anything back then), so you couldn’t even type e.g. a callback-invoking function properly. Otherwise, yes, as well as the discussions about monad transformers in Haskell from 15 years ago. Effects are effects are effects.
- layer8 1y ago
  You can abstract over a finite set of exception types in Java with generics, but it doesn’t always work well for n > 1 and is a bit boilerplate-y. The discussions I was referring to predate generics, however.

Expurple 1y ago

That's only the case when your per-function error sets are "flat" (directly contain "leaf" errors from many layers below). You can avoid this issue if you deeply nest the error types (wrap on every level). It you change an error that's not deeply-matched anywhere, you only need to update the direct callers. But "deep" errors have some tradeoffs [1] too [1]: https://news.ycombinator.com/item?id=44420061 https://news.ycombinator.com/item?id=44420061