4 ms·

I understand golang was an attempt to fix c's shortcomings and not to create the next c++ or java. But I also understand programmers get their way of doing thi

I understand golang was an attempt to fix c's shortcomings and not to create the next c++ or java. But I also understand programmers get their way of doing things that are bad. Case in point, people who do println("entering function doit()"); println ("exiting function doit()"); for every function in the entire codebase because it's how they learned to "debug" and they never tried anything better. Error returns in golang are like that. It has to be for every function in the codebase and balloons the code by a non-trivial percent. As for performant, as of at least ten years ago it became impossible for a person to perceive a performance increase by removing exception handling. A human can't perceive the microseconds.

erik_seaberg 6y ago
Does go actually generate machine code that continually checks for err != nil? Because that can be more expensive than generating an unwind table and ignoring it until an exception actually happens.
sethammons 6y ago
> As for performant, as of at least ten years ago it became impossible for a person to perceive a performance increase by removing exception handling. You are really hung up on the exception handling. I never claimed that the error handling made Go more performant. I wrote "performant" as in "there are other things that are important that should be taken into consideration aside from use of exceptions". It might not be as apparent to others now as you edited your original response that was along the lines of "not using exceptions is the worst software decision of all time." (note I don't recall the exact thing you wrote, but that feels close). As for the new edit you have: > litered everywhere with if err != nil... garbage I just grepped one of my Go code bases. It is 40,636 lines of code. It has 326 "if err !=" lines. Less than 1% of the lines are for error handling preamble, and we take our error handling very serious. In fact, a lot of those error checks don't directly bubble up. They perform fallback logic, logging and/or metrics, or set sane default values. Sure, some bubble up, but it is less than half as grep suggests 134 bubble up. What I value about local error checking is that everything you need is right in front of you as a reader of the code. When I worked in Twisted Python, one particularly bad case of exception handling made it so I literally could not use ErrBacks in one part of the code because in some other module someone used an exception for a non-exceptional error.

erik_seaberg 6y ago

Does go actually generate machine code that continually checks for err != nil? Because that can be more expensive than generating an unwind table and ignoring it until an exception actually happens.

sethammons 6y ago

> As for performant, as of at least ten years ago it became impossible for a person to perceive a performance increase by removing exception handling. You are really hung up on the exception handling. I never claimed that the error handling made Go more performant. I wrote "performant" as in "there are other things that are important that should be taken into consideration aside from use of exceptions". It might not be as apparent to others now as you edited your original response that was along the lines of "not using exceptions is the worst software decision of all time." (note I don't recall the exact thing you wrote, but that feels close). As for the new edit you have: > litered everywhere with if err != nil... garbage I just grepped one of my Go code bases. It is 40,636 lines of code. It has 326 "if err !=" lines. Less than 1% of the lines are for error handling preamble, and we take our error handling very serious. In fact, a lot of those error checks don't directly bubble up. They perform fallback logic, logging and/or metrics, or set sane default values. Sure, some bubble up, but it is less than half as grep suggests 134 bubble up. What I value about local error checking is that everything you need is right in front of you as a reader of the code. When I worked in Twisted Python, one particularly bad case of exception handling made it so I literally could not use ErrBacks in one part of the code because in some other module someone used an exception for a non-exceptional error.