Thank you for filing this issue @master255!

Your report currently is not actionable because it provides a single line of code without context of what could be going wrong, nor the stacktrace of the panic. Could you please provide a minimized complete runnable reproducer for the panic as well as the stacktrace? Thank you.

No. That's impossible. Panic triggers unsteadily and I don't know what it's related to.

seems like a problem of your code rather than the standard library.

@seankhliao But here in the code you can see that panic is called, and the method returns an error and should not call panic. Why do you ignore it?

it violates invariants of the system that make it unsafe to continue, a panic is appropriate.

@seankhliao No, it's not. It is necessary that json.Unmarshal does not cause panic. How do I do that?

@seankhliao Are you a programmer without logic?

@master255 Please respect the code of conduct. Thanks.

@atdiar Maybe you can explain what's going on here?
I cite a significant bug in the code, but no one wants to fix it.
The code is developed as people want it, not as logic dictates?
Is logic used in Golang development?

@master255

If the implementation has an error, there is no point in returning an error.
The system is broken. It's better to panic then.
That's what this panic does I believe.
Errors are for things that should be possible such as an input that can't be processed because it has a mistake.

Panic (here) is for when the processing itself encountered an impossible value which means somehow the implementation allows for an impossible state.

That's why it is surprising that you come across such a panic.

As @odeke-em said, perhaps you can provide a stacktrace, reproducer for the panic you receive. It might be unrelated to this code as @seankhliao mentions.

If you read the code, it says:

// phasePanicMsg is used as a panic message when we end up with something that
// shouldn't happen. It can indicate a bug in the JSON decoder, or that
// something is editing the data slice while the decoder executes.

So you could investigate the latter part, perhaps. Maybe you have a race?

@atdiar I want a very simple thing - not to get panic in json.Unmarshal. That my application won't completely terminate because of it.
All other languages have try catch and that fixes the problem.
Golang has no try catch. So there should be no panic here if an error is supposed to be returned. Under any circumstances!
Even if the data is being edited while json.Unmarshal is happening.
I want to get an error and ignore it or react somehow.
And I'm very surprised that such simple things it is necessary to explain to people here. This is something new.

If the unmarshalling panics, you have a bigger problem than it not returning an error.

That's the point of panicking here.

If your code is correct, it should never even hit that case so this is not something to worry about.
If you have a race in your code, might as well panic too.

@atdiar try catch catches any problem. What makes you think there are big and small problems at all? All problems are equal. If even a small error occurs, the application stops working. Just like when a big error occurs.
So it is not logical to cause panic for a certain kind of error and not for another kind of error.

Panics are recoverable.
If that's really what you need, I recommend reading:

https://go.dev/blog/defer-panic-and-recover

@atdiar But it is necessary for me to ignore the error and continue executing the program (method). Not to catch the error. How do I do that?

Perhaps that you can use a closure to call your json.Unmarshal

For questions please refer to https://github.com/golang/go/wiki/Questions