| |||||||||||||
Google's new "Go" languageGoogle's new "Go" languagePosted Nov 13, 2009 11:25 UTC (Fri) by farnz (guest, #17727)In reply to: Google's new "Go" language by ibukanov Parent article: Google's new "Go" language
But now, you've made the contents of f(), g() and h() uglier. Every function has to look something like:
function( ok, ... )
{
if( !ok )
return;
manipulate ...
}
Otherwise, what stops you getting into a state where f() was supposed to set up the world ready for h(), g() was supposed to modify that set up slightly (but fails in interesting and unfriendly ways, because the state that should have been created by f() doesn't exist), and h() bombs badly because the state it expected didn't exist at all, due to f() failing? Further, every function needs a valid return value for the early exit case. This all just feels to me like a bad reinvention of exceptions, and I don't see how it's any better.
(Log in to post comments)
Google's new "Go" language Posted Nov 13, 2009 13:04 UTC (Fri) by ibukanov (subscriber, #3942) [Link]
> you've made the contents of f(), g() and h() uglier
Yes, but if the function has more then one call site (very typical), the ugliness is limited to the function itself, not to all its callers.
> Further, every function needs a valid return value for the early exit
The most difficult case is when returning an allocated memory/object. If one just returns a null, the following crashes:
a = f(ok);
To deal with such cases one can return a special statically allocated object.
With such tricks the overall impression from a code written 15 years ago in that style was a surprisingly clean and easy to reason about code with ugliness limited mostly to parts that interacts with system API.
Google's new "Go" language Posted Nov 13, 2009 13:32 UTC (Fri) by farnz (guest, #17727) [Link] So basically, I get all the pain of return codes (having to mess up all my computation code with error handling logic to pass ok around and deal with it correctly when something goes wrong), and I get none of the benefits of exceptions (being able to write code that ignores errors when I cannot think of a sensible way to handle them)? Doesn't sound like a good tradeoff to me; the big benefit of exceptions is that it's easy to let them propogate upwards when I can do nothing about the error (the common case). The only code that ends up looking ugly is code which knows how to cope with errors, not code that can't do anything sensible. In some cases (such as tiny tools), the only sensible thing to do is use an outer wrapper that reports the error (usually language provided, as in Python's tracebacks). In others (such as the application I work on), there are certain errors which I can catch and do something sensible about (e.g. absence of required files triggers me to create default versions). I really can't see how having to add huge piles of ugly error state passing code all over the application would make it neater.
Google's new "Go" language Posted Nov 13, 2009 13:29 UTC (Fri) by hppnq (guest, #14462) [Link] There is one simple rule that applies here, I guess: refactor your code.
|
|||||||||||||