3 ms·

My point is that translating an error from one call to the previous is neither generic nor pointless. An exception and line-number (and a call-stack dump) is g

by sambeau 13y ago

My point is that translating an error from one call to the previous is neither generic nor pointless. An exception and line-number (and a call-stack dump) is great for a developer, but a good textual error message is needed for a real user.

zellyn 13y ago
I agree with sambeau on this one. I have come to like the go way of doing things: it's extremely simple, doesn't take much thought, and after a little while is very easy to read.
masklinn 13y ago
> My point is that translating an error from one call to the previous is neither generic nor pointless. The first pattern does not do that. The second one is still mostly pointless generic boilerplate: blah, err := if err != nil { return nil, errors.New() } is all boilerplate, only two parts are not: the call itself and the error message. > An exception and line-number (and a call-stack dump) is great for a developer, but a good textual error message is needed for a real user. 1. having exceptions doesn't preclude handling them and writing user-readable error messages 2. exceptions are not the only alternative to C-style error handling
- notok22 13y ago
  Can you tell me about the other alternatives? I'm actually interested in this and I have searched for alternatives at least to see how they look.
  - masklinn 13y ago
    I'm sure I don't know most of them (e.g. I have no idea how Prolog does error handling), but I know of: * the Haskell/ML statically typed approach, error possibility is type-encoded through an Option or Either type; even in cases where it is possible to implicitly ignore return values[0] the compiler will warn or error; the standard library provides high-level operations to pipeline results (build a pipeline of operations which will only transform non-erroneous results, and will let errorneous ones go through) * the Erlang dynamically typed approach which makes use of tagged pattern matching to make value assertions trivial. It is not shorter than the Go version when fully handling things, but assertion can be used to fault processes during development or when in-process user-visible reporting is irrelevant (fairly common in erlang) yet remain easy to find and replace with more involved handling if needs be [0] because haskell strives for purity, ignoring return values in non-monadic code makes very little sense and I'm not sure it's possible at all short of unsafe* functions. It is possible in monadic code (e.g. do blocks)

by sambeau 13y ago

zellyn 13y ago

I agree with sambeau on this one. I have come to like the go way of doing things: it's extremely simple, doesn't take much thought, and after a little while is very easy to read.

masklinn 13y ago

> My point is that translating an error from one call to the previous is neither generic nor pointless. The first pattern does not do that. The second one is still mostly pointless generic boilerplate: blah, err := if err != nil { return nil, errors.New() } is all boilerplate, only two parts are not: the call itself and the error message. > An exception and line-number (and a call-stack dump) is great for a developer, but a good textual error message is needed for a real user. 1. having exceptions doesn't preclude handling them and writing user-readable error messages 2. exceptions are not the only alternative to C-style error handling

notok22 13y ago
Can you tell me about the other alternatives? I'm actually interested in this and I have searched for alternatives at least to see how they look.
- masklinn 13y ago
  I'm sure I don't know most of them (e.g. I have no idea how Prolog does error handling), but I know of: * the Haskell/ML statically typed approach, error possibility is type-encoded through an Option or Either type; even in cases where it is possible to implicitly ignore return values[0] the compiler will warn or error; the standard library provides high-level operations to pipeline results (build a pipeline of operations which will only transform non-erroneous results, and will let errorneous ones go through) * the Erlang dynamically typed approach which makes use of tagged pattern matching to make value assertions trivial. It is not shorter than the Go version when fully handling things, but assertion can be used to fault processes during development or when in-process user-visible reporting is irrelevant (fairly common in erlang) yet remain easy to find and replace with more involved handling if needs be [0] because haskell strives for purity, ignoring return values in non-monadic code makes very little sense and I'm not sure it's possible at all short of unsafe* functions. It is possible in monadic code (e.g. do blocks)