There is also the idea that an error is not necessarily an error in the
sense that it is wrong but it is something that prevents the operation. It
could be that the far end is out of service or the network connection is
down or the port is closed or the file permissions are set to what is not
expected (once we missed a big revenue recognition opportunity at the end
of the quarter because the file permissions were set to something we did
not expect and we ran out of time during the maintenance window and had to
back out the upgrade and wait for the next quarter). In real life, they
are real situations that must be handled. Dave Cheney in his blog
discusses this extensively. In a way, thinking through the collection of
events that prevent the happy path from proceeding must be thought through
first.
So, it pays to think of what could go wrong and handle it before anything
else.
On Thursday, June 4, 2020 at 11:44:07 AM UTC-4, lgo...@gmail.com wrote:
>
> ?? Why not a cleaner syntax e.g. x = some_func () #{ } .. symbol #
> arbitrarily chosen
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/b961c216-2fdd-45b3-837c-7933e8b89317o%40googlegroups.com.
