4 ms·
> You could use Either, but it doesn't give you any guarantee that you'll get a string back 1. It's better not to use strings and instead use a user defined er
by codygman 12y ago
> You could use Either, but it doesn't give you any guarantee that you'll get a string back
1. It's better not to use strings and instead use a user defined error type.
2. What do you mean "doesn't give you any guarantee you'll get a string back"?
> real error-reporting mechanism should support cause chaining so you can see the dependencies;
Can you elaborate on cause chaining, perhaps with an example?
- skybrian 12y agoWhat I mean is something like a stack trace except without all the extra detail: - Can't persist shopping cart - RPC request failed: http://example.com/update_cart - Can't write to database "carts" - Can't save file: "/a/b/c" - OS error: disk full Ideally, all errors in the cause chain should be logged, and they typically cross abstraction boundaries; the message at each level comes from a different part of the stack. This seems hard to do across languages, but within a language there should be a standard way to do it. (Go falls down on this too. Perhaps we don't need Java-style stack traces that go on for multiple screens, but we should have more than a string.)