← Back to context

Comment by xorcist

2 days ago

This argument is weak. C, and specifically libc, has errno. The error code is there. Not in band.

But there has to be something in the payload field when it is not applicable. A null is perfectly fine.

The argument for changing that to "*", if I understand the above linked discussion correctly, was that some users of this api threw away errors and a dummy value would be harder to ignore. Maybe one could argue that these behaviours are less common in Rust or Go, but not because of a technical difference.

The world is not perfect and sometimes you really need to work around bad users. Even in Rust or Go. I am not convinced this was such a case. If you are convinced it was it would still have been better to select a less trivial dummy value (such as "*:ERROR:*").

> But there has to be something in the payload field when it is not applicable

Not in languages with ergonomic sum types. A `Result` or `Either` will have no payload field on the error type. The compiler won't let you dereference it.

In Haskell, one would return a Maybe or an Either here.

    Maybe
    ——————
    Just hash
    Nothing

    Either
    ——————————
    Left err
    Right hash

The program would be designed around not allowing this failure mode to even be possible.

This is wrong. errno is not to be used to detect errors, only to get the cause of the error once an error has been detected.