An example is nil map access or concurrent map access both cause panics in
the runtime
(https://github.com/golang/go/blob/release-branch.go1.10/src/runtime/hashmap.go#L357).
A useful thing panic without recover does is print the stack trace.
Matt
On Saturday, May 19, 2018 at 11:57:33 AM UTC-5,
https://play.golang.org/p/d_fQWzXnlAm
If you are going to use panic, then choose a place where you can recover
gracefully and report the error.
I do agree, that it is an mistake to return an error code if your
assignment was to write a function that only has valid input. The software
engineer giv
I may have misunderstood the question. I follow the idea of panic when the
program is in an invalid state.
If Divide can receive any input then this is probably a better API:
func Divide(a, b float64) (float64, error) {
where you would return an ErrDivideByZero made with errors.New as a global
I agree with Matt, using panic is fine when you are debugging. I do not
usually do panic in production code unless it is because of the loss of
some asset required to start.
GO has robust error handling. You should write the function to return an
error.
If you deploy your program to a client s
What I’ve seen in the standard library was no named asserts like this, just
if checks with panics. The panic functionality does what you’ve described.
Personally I prefer the look of if+panic instead of another function for
this.
Matt
On Monday, May 14, 2018 at 7:38:32 PM UTC-5, Tristan Muntsi
