Adding more context for invalidUnmarshalError management inside readJSON function. Updating 'Panicking vs returning errors' section.
All checks were successful
Deploy Greenlight API / deploy (push) Successful in 54s
All checks were successful
Deploy Greenlight API / deploy (push) Successful in 54s
This commit is contained in:
@@ -172,6 +172,10 @@ The other class of errors are _unexpected errors_.These are errors which should
|
||||
|
||||
I'd recommend trying to return and gracefully handle unexpected errors in most cases. The exception to this is when _returning the error_ adds an unacceptable amount of error handling to the rest of your codebase.
|
||||
|
||||
'Go By example' page on panics summarizes all of this quite nicely:
|
||||
|
||||
_A panic typically means something went unexpectedly wrong. Mostly we use it to fail fast on errors that shouldn't occur during normal operation and that we aren't prepared to handle gracefully._
|
||||
|
||||
### Performance
|
||||
|
||||
**json.MarshalIndent()** takes 65% longer to run and uses around 30% more memory than **json.Marshal()**, as well as making two more heap allocations. Those figures will change depending on what you're encoding, but they're fairly indicative of the performance impact.
|
||||
|
||||
Reference in New Issue
Block a user