Hacker News new | past | comments | ask | show | jobs | submit login

> 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.




> 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)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: