4 ms·
To illustrate my point: If I implemented some network program which converses with a remote server in multiple steps in an language with exceptions and somethin
by thwd 10y ago
To illustrate my point: If I implemented some network program which converses with a remote server in multiple steps in an language with exceptions and something fails I might get a stack trace and the message:
"Syntax error, expected token HTTP_METHOD but got 'B'"
In Go, with proper error handling I'd get a message like:
"Couldn't do flubber transfer: Unable to negotiate protocol: Sent supported protocols but remote responded with HTTP 400 "Bad Request": Missing required field 'version' in protocol definition"
As "error" is an interface, this message is only the tip of the iceberg: the error object itself may contain the address of the remote server, the protocol definitions that were sent, the response body that we got and any other relevant contextual payload.
This is all due to the error being treated in-context as opposed to just bubbling up.
- aninhumer 10y ago>In Go, with proper error handling Well yeah, if you handle errors properly, you get better results than if you don't. The point is that with exceptions, it fails loudly and you get the cryptic message even if you forget, whereas with Go, if you forget to handle an error, you just get weird behaviour and corrupt data. And if you want more helpful error messages, you can catch the exceptions and report the context just as easily as you can in Go.