3 ms·

If you don't mind me asking, what do you think of Go-style error handling where there are multiple return types: one exclusively for errors and however many for

• jstimpfle 9y ago
  I think there is not much difference. I used that approach myself once when writing a simple parser in python. I think it lacks some elegance, but it may be better than out-arguments (pointer argument to return value). On the other hand, the two-variables handling has the disadvantage that the "real" return variable is always (over)written, also in case of error. I think there is one underused error handling mechanism: "asynchronous error handling" where you have to to ask for errors explicitly. Like in the OpenGL API, for example. It might be the best choice where there is a lot of communication between largely isolates states. So that could be one answer: If possible design the API in such a way that functions that can have expected errors [1] do not return values that only make sense if there was no error. Because this means that control flow gets very irregular on the calling side. Such a design could be hard to do though, I don't know. The other answer could be: Don't have errors that you don't know how to handle. Unless you write very low-level code, like a library (which means you probably want to delegate the handling), just die on errors that you don't know how to handle. Make the die() call a best-effort cleanup routine if possible, and keep the important to-be-cleaned up state as global as possible (NOT on the call stack), to support such a cleanup routine. [1] I hate the vagueness of that term, but take it to mean "no statically obvious wrong usage by the caller", like passing in made-up or corrupted values