4 ms·

I would say that you are using them incorrectly if you assume them as recoverable. You should make everything you can so that they never happen. However, since

by nicce 2y ago

I would say that you are using them incorrectly if you assume them as recoverable. You should make everything you can so that they never happen. However, since it is still possible to have them in a place where the exiting the process is not okay, it was beneficial to add a way to recover from them. It does not mean that they are designed to be recoverable. > this is where most of it's overhead comes from Overhead comes from the cleaning process. If you don't clean properly, you might leak information or allocate more resources than you should.

dathinab 2y ago
> I would say that you are using them incorrectly if you assume them as recoverable. no it's them being recoverable at well defined boundaries is a _fundamental_ design aspect of rust > Overhead comes from the cleaning process. If you don't clean properly, you might leak information or allocate more resources than you should. and that same cleanup process makes it recoverable
- nicce 2y ago
  Even the book uses the word "unrecoverable". The wording is communication. The intention is not to recover them, while it could be possible. https://doc.rust-lang.org/book/ch09-01-unrecoverable-errors-with-panic.html https://doc.rust-lang.org/book/ch09-01-unrecoverable-errors-...
  - sieabahlpark 2y ago
    [dead]
- sunshowers 2y ago
  There is a social norm to treat panics as unrecoverable (in most cases — some do use panics to perform cancellation in non-async code).
  - dathinab 2y ago
    they are still anyway designed to be recoverable as a fundamental aspect of rust so that e.g. you web server doesn't fall over just because one request handler panics and it still is fundamental required that any code is safe in context of panic recovery (UnwindSafe is misleading named and actually not about safety, anything has to be "safe" in context of unwind, UnwindSafe just indicates that it's guaranteed to have sensible instead of just sound behavior in rust) people over obsessing with panic should be unrecoverable is currently IMHO on of the biggest problems in rust not in line with any of it's original design goals or how panics are in the end design to work or how rust is used in many places in production yes they are not "exceptions" in the sense that you aren't supposed to have fine grained recoverablility, but recoverability anyway without recoverable panics you wouldn't be able to write (web and similar) servers in a reasonable robust way in rust without impl some king of CGI like pattern, which would be really dump IMHO and is one of the more widely used rust use cases
    - sunshowers 2y ago
      At Oxide we ship our binaries, including our HTTP servers, with panic = abort, fwiw.
      - dathinab 2y ago
        I know some do. But as long as you don't do anything unusual you are basically introducing a (potentially huge) availability risk to your service for no reason but except not liking panics. Like it's now enough for there to be a single subtle bug causing a panic to have a potentially pretty trivially exploitable and cheap DoS attack vector. Worse this might even happen accidentally. Turning a situation where some endpoints are unavailable due to a bug into one where your servers are constantly crashing. Sure you might gain some performance, but for many use cases this performance is to small to reason in favor of this decisions. Now if you only have very short lived calls, and not too many parallel calls in any point in time, and anyway spread scaling across many very very small nodes it might not matter that you might kill other requests, but once that isn't the case it seems to most times be a bad decision. It also doesn't really add security benefits, maybe outside of you having very complicated in memory state or similar which isn't shared across multiple nodes through some form of db (if it is, you anyway have state crossing panics, or in your case service restarts).

by nicce 2y ago

dathinab 2y ago

> I would say that you are using them incorrectly if you assume them as recoverable. no it's them being recoverable at well defined boundaries is a _fundamental_ design aspect of rust > Overhead comes from the cleaning process. If you don't clean properly, you might leak information or allocate more resources than you should. and that same cleanup process makes it recoverable

nicce 2y ago
Even the book uses the word "unrecoverable". The wording is communication. The intention is not to recover them, while it could be possible. https://doc.rust-lang.org/book/ch09-01-unrecoverable-errors-with-panic.html https://doc.rust-lang.org/book/ch09-01-unrecoverable-errors-...
- sieabahlpark 2y ago
  [dead]
sunshowers 2y ago
There is a social norm to treat panics as unrecoverable (in most cases — some do use panics to perform cancellation in non-async code).
- dathinab 2y ago
  they are still anyway designed to be recoverable as a fundamental aspect of rust so that e.g. you web server doesn't fall over just because one request handler panics and it still is fundamental required that any code is safe in context of panic recovery (UnwindSafe is misleading named and actually not about safety, anything has to be "safe" in context of unwind, UnwindSafe just indicates that it's guaranteed to have sensible instead of just sound behavior in rust) people over obsessing with panic should be unrecoverable is currently IMHO on of the biggest problems in rust not in line with any of it's original design goals or how panics are in the end design to work or how rust is used in many places in production yes they are not "exceptions" in the sense that you aren't supposed to have fine grained recoverablility, but recoverability anyway without recoverable panics you wouldn't be able to write (web and similar) servers in a reasonable robust way in rust without impl some king of CGI like pattern, which would be really dump IMHO and is one of the more widely used rust use cases
  - sunshowers 2y ago
    At Oxide we ship our binaries, including our HTTP servers, with panic = abort, fwiw.
    - dathinab 2y ago
      I know some do. But as long as you don't do anything unusual you are basically introducing a (potentially huge) availability risk to your service for no reason but except not liking panics. Like it's now enough for there to be a single subtle bug causing a panic to have a potentially pretty trivially exploitable and cheap DoS attack vector. Worse this might even happen accidentally. Turning a situation where some endpoints are unavailable due to a bug into one where your servers are constantly crashing. Sure you might gain some performance, but for many use cases this performance is to small to reason in favor of this decisions. Now if you only have very short lived calls, and not too many parallel calls in any point in time, and anyway spread scaling across many very very small nodes it might not matter that you might kill other requests, but once that isn't the case it seems to most times be a bad decision. It also doesn't really add security benefits, maybe outside of you having very complicated in memory state or similar which isn't shared across multiple nodes through some form of db (if it is, you anyway have state crossing panics, or in your case service restarts).