[littlestymaar]

> which removes any temptation to use them for user errors.

It doesn't look to be too much of a temptation to use panics as regular errors in Rust though, so I don't think it gains you much.

And it makes it more complicated when you want to catch panics for legitimate reasons (like when you want to show an error box to the user, instead of silently crashing, or when you want to send the crash log for later analysis). It's still possible, by using a separate process, but it's unnecessary friction in order to prevent a sin that doesn't happen in practice.

[Zambyte]

> It doesn't look to be too much of a temptation to use panics as regular errors in Rust though

Maybe not, but it was enough for the author to dedicate at least one whole section of the article to reasoning about this.

> like when you want to show an error box to the user, instead of silently crashing, or when you want to send the crash log for later analysis

As I mentioned, panics can be handled but not recovered. You can use the panic handler to do these things just fine. Just not recover.

[littlestymaar]

> As I mentioned, panics can be handled but not recovered. You can use the panic handler to do these things just fine. Just not recover.

What does this difference mean? If you can run arbitrary function in your panic handler, what prevents someone from continuing the program?

[Zambyte]

The stack is fully unwound before running the panic function, including the main stack frame. This will run all deferred deallocation statements, and pretty much leave you with nothing to do but exit. You could try to launch the program again automatically, but there is little reason to do that most likely. The user will still see the application terminate and launch again.

[jvanderbot]

I've never heard of anyone using panic for exception-style recovery. That's anathema to the whole idea of Result<T,V>. But I suppose if it's possible, it will be normal for someone.

[Zambyte]

I'm not as familiar with the Rust ecosystem, but I know it is used all the time in Go. For example, the standard http server library wraps user provided endpoint handler functions with panic handlers.

[dhruvrajvanshi]

I suppose it's a matter of perspective but I don't see returning a 500 as "Recovering from the error". The user's request has still failed. It just hasn't taken down the server. IMO this is still fine.

[Zambyte]

It is quite literally using the "recover" function in go, so I think it's accurate to call it "recovering".

> this is fine

I didn't mention the merit, just that it is exception style control flow.

[Zambyte]

Reading my top level comment again, I realized I did refer to the Zig way as "nice" relative to the exception style control flow.

[nicoburns]

Is that used for application-level errors though? Rust web servers do that too, but it is used a fallback to avoid bringing down the whole server due to an unexpected crash. It is not a mechanism you would use intentionally.

[Zambyte]

Probably not. I have never used panic / recover in application code at least.

[9rx]

encoding/json uses uses exception handlers for control flow.