4 ms·
I get that what you’ve posted is the official description but it doesn’t really explain the distinction well IMO. Eg there are plenty of environmental reasons y
by laumars 5y ago
I get that what you’ve posted is the official description but it doesn’t really explain the distinction well IMO. Eg there are plenty of environmental reasons you’d need to cease execution but giving the user a stack trace isn’t helpful. So be describing the two as who the target recipient of the error is helps. Or at least I think it does.
Personally my one gripe with Gos errors is that EOF is handled as an error.
- konart 5y ago> Eg there are plenty of environmental reasons you’d need to cease execution but giving the user a stack trace isn’t helpful. Not sure I got this part. If you want to stop the program and don't to print the usual panic messages into the console - you can log\print whatever you want and call os.Exit(). At the same time you can log stack trace without panicing. >Or at least I think it does. Maybe, it's just that "the code has failed and the developer needs to be informed what to fix" applies to errors just a much as to panics. The only difference is that an error is the situation during the execution where you can continue the job and a panic requires execution to stop (in most cases). At the same time panic are 'developers only'.
- laumars 5y agoYou’re arguing the same points I’m making :)