3 ms·
> On the other hand, exceptions are implicit control flow Go doesn't force you to deal with errors either. I see plenty of code ignoring them with retval ,
by aikah 11y ago
> On the other hand, exceptions are implicit control flow
Go doesn't force you to deal with errors either. I see plenty of code ignoring them with
retval , _ := MightYieldAnError();
And some languages that have exceptions actually force the client code to handle them, like Java AFAIK .
Finally, Go "explicit control flow" didn't have to be verbose like it is, that's a design choice its authors made.
Go is primitive in the sense that it uses C style code patterns , like the famous :
retval = MightYieldAnError( &outError);
Edit: I forgot to mention the panic/recover which ultimately means Go designers implemented some form of exceptions. That basically voids the usefulness of Go error system, and an admission that it's broken.
- jjnoakes 11y ago> Go doesn't force you to deal with errors either. > And some languages that have exceptions actually force the client code to handle them, like Java AFAIK. But this misses the point. Any error which you have to explicitly ignore is fine, because then you were aware of it at some point and explicitly ignored it, and anyone reading the code can plainly see you explicitly ignoring them. And errors which can only happen at specific points (like function return values) are also ok, because then you only have to consider error handling and cleanup at those points. But if you have neither of the above - if you have the situation where errors can spontaneously result from any evaluation of any expression with no explicit notation required - then you have a poor situation indeed.