5 ms·

> You’d obviously never do this for untrusted code. Doesn't panic imply that the program entered a state from which it was never explicitly designed to recover

> You’d obviously never do this for untrusted code. Doesn't panic imply that the program entered a state from which it was never explicitly designed to recover? Since that state may persist across invocations of a function, doesn't that make the code effectively 'untrusted' for subsequent execution?

ninkendo 4y ago
> Doesn't panic imply that the program entered a state from which it was never explicitly designed to recover? No? I think you’re making a lot of assumptions about the “state” of a program. Panicking doesn’t mean “I maintain state in between requests and that state is now poison and I can’t be called again”. In fact it doesn’t mean anything really. It means someone wrote a code path that panics, no more, no less. Sure it’s possible that code can be written where a panic indicates that there is some poison state and now nothing can be trusted etc. But… the same is possible for code that doesn’t panic, so I don’t really know where we’re going with this discussion.
- lmm 4y ago
  Well, shouldn't there be a standard way to convey that, that is understood (as a matter of culture) to mean that? And if it's not panic then what is it?
  - ninkendo 4y ago
    You want there to be a language-standard way of saying “I’m a backend for a web server and I don’t want to cause an error 500 but instead I want to crash the whole process”? Seems pretty specific to me. Panic means “something’s wrong, this error isn’t recoverable”. In most contexts, the best thing to do is crash in this case. In some specific cases, if you keep things well-isolated enough (making HTTP handlers stateless, etc) you can design a system where panic means “something’s wrong, this error isn’t recoverable, and inform the remote end as such by rendering a 500 error”, and everything works just fine. You seem to want some sort of truly fatal way of conveying errors. Panic is not that. If it was, Rust would not have designed panic to be handleable. It would be called “crash”, not panic. Go is similar… go’s panic is not meant for typical error handling, but it’s not synonymous with “crash”, either. It’s meant for situations where you want the moral equivalent of a crash, but taking the form of whatever makes sense for your use case. A multiplexing web server that renders proper 500 errors on a panic is basically the premiere use case doe this.
    - int_19h 4y ago
      Panic means "something wrong and this system didn't anticipate it, so now any random invariant might be broken". Or at least that's what it was back when people first started making the distinction vs handle-able errors. I guess it got skewed over time, just like everything else.

ninkendo 4y ago

> Doesn't panic imply that the program entered a state from which it was never explicitly designed to recover? No? I think you’re making a lot of assumptions about the “state” of a program. Panicking doesn’t mean “I maintain state in between requests and that state is now poison and I can’t be called again”. In fact it doesn’t mean anything really. It means someone wrote a code path that panics, no more, no less. Sure it’s possible that code can be written where a panic indicates that there is some poison state and now nothing can be trusted etc. But… the same is possible for code that doesn’t panic, so I don’t really know where we’re going with this discussion.

lmm 4y ago
Well, shouldn't there be a standard way to convey that, that is understood (as a matter of culture) to mean that? And if it's not panic then what is it?
- ninkendo 4y ago
  You want there to be a language-standard way of saying “I’m a backend for a web server and I don’t want to cause an error 500 but instead I want to crash the whole process”? Seems pretty specific to me. Panic means “something’s wrong, this error isn’t recoverable”. In most contexts, the best thing to do is crash in this case. In some specific cases, if you keep things well-isolated enough (making HTTP handlers stateless, etc) you can design a system where panic means “something’s wrong, this error isn’t recoverable, and inform the remote end as such by rendering a 500 error”, and everything works just fine. You seem to want some sort of truly fatal way of conveying errors. Panic is not that. If it was, Rust would not have designed panic to be handleable. It would be called “crash”, not panic. Go is similar… go’s panic is not meant for typical error handling, but it’s not synonymous with “crash”, either. It’s meant for situations where you want the moral equivalent of a crash, but taking the form of whatever makes sense for your use case. A multiplexing web server that renders proper 500 errors on a panic is basically the premiere use case doe this.
  - int_19h 4y ago
    Panic means "something wrong and this system didn't anticipate it, so now any random invariant might be broken". Or at least that's what it was back when people first started making the distinction vs handle-able errors. I guess it got skewed over time, just like everything else.