|
|
|
|
|
|
by nicerobot
3667 days ago
|
|
|
> I think would try to use its panic/recover mechanism as much as possible And that's exactly the reason you should avoid Go. Every error is not exceptional. Most errors are not exception. Hence, most errors should not panic. > to avoid the tedious multi-level error handling. It only looks tedious to the uninitiated based on code snippets you've probably seen. Or if you're stuck in an imperative paradigm, i can imagine Go will feel tedious. But since Go has first class functions, it's quite easy to write high-order functions that work better than try/catch and make error handling flow quite nicely. It also provides better error handling than cumbersome, coarse-grained, and verbose try-catch clauses where the catch clause is not directly related to the call that produced the exception (which probably isn't really an exceptional case but rather just a simple error.) https://gist.github.com/nicerobot/263869942dd5344d9cd6943af5... Yea, Python can do the same but because Exceptions exist, everyone considers simple errors to be exceptional. Go allows errors to just be errors and error handling becomes related directly to the call that caused the error. |
|
|
Lower-level code often doesn't "know" how to handle a situation when it is not able to complete its job. The executive decision about how to proceed is somewhere higher up.
Returning an error code that has to be propagated through several levels to the appropriate place is blub programming that belongs to the 1960's.
Higher order functions are useful for error handling, but only when coupled with a dynamic control transfer. The low-level routine invokes a callback, which is some closure belonging to a higher level. For this architecture to be useful to its full potential, that closure must be able to make a jump (for example, a jump to the surrounding code in the function where that closure was created, to effectively abort all the frames between that function and the low level where the error occurred).