Hacker News new | ask | show | jobs
by jammycakes 1034 days ago
If you want to (and are able to) document all possible failure modes, then checked exceptions will give you that. As far as I can tell, railway oriented approaches can't.

Unfortunately, you can only do that when the number of possible failure modes is fairly limited. In a complex codebase with lots of different layers, lots of different third party components, and lots of different abstractions and adapters, it can quickly become pretty unwieldy. And then you end up with someone or other deciding to take the easy way out and declaring their method as "throws Exception" which kind of defeats the purpose.
2 comments
catiopatio 1034 days ago
No; you simply abstract the underlying subsystem’s exceptions in your own types, the same way you do with any other type.

And yes, “railway oriented approaches” can absolutely do this.

link
jammycakes 1034 days ago
> No; you simply abstract the underlying subsystem’s exceptions in your own types, the same way you do with any other type.

That's all very well as long as people actually do that. It doesn't always happen in practice. And even when they do, the abstractions are likely to be leaky ones.

> And yes, “railway oriented approaches” can absolutely do this.

How? Please provide a code sample to demonstrate how you would do so.

link
catiopatio 1034 days ago
> That's all very well as long as people actually do that. It doesn't always happen in practice. And even when they do, the abstractions are likely to be leaky ones.

They don’t have a choice under “railway oriented” API in a typesafe language — they must translate the subsystem’s error types to their own error type.

If the abstraction is leaky, at least it’s well-specified.

How is that worse than having no abstraction at all, and leaving callers with no idea what error cases an API might raise?

> How? Please provide a code sample to demonstrate how you would do so.

In what language? What data structure?

If we assume Haskell and Either, then it can be as trivial as:

  first mapError someResult
Scala’s Either?

  someResult.left.map(mapError)
link
layer8 1034 days ago
You adjust the reported failure modes to the abstraction level of the respective function, wrapping underlying exceptions if necessary. You don’t leak implementation details via the exception types. Callers can still unwrap and inspect the underlying original exceptions if they want, but their types won’t typically be part of the function’s interface contract, similar to how specific subtypes of the declared exception types are usually not part of the contract.
link