4 ms·

That's why you have wrappers that return Result enumerations. There is an overhead to check if an operation is valid, pay for it if you need it. This is exactl

That's why you have wrappers that return Result enumerations. There is an overhead to check if an operation is valid, pay for it if you need it. This is exactly how Rust works, for example.

demurgos 2y ago
Rust's panics are recoverable, so they're more like exceptions. This means that you may need to care about "unwind" safety and values in a potentially invalid state. It's the main reason for mutex poisoning and having to deal with it when locking. Overall, I'm not entirely sure if Rust would be better or not if panics were non-recoverable. PS: For completeness, there are flags to control the panic behavior; but you can't rely on them when writing a lib.
- ryang2718 2y ago
  Unless a library developer decides to abort on panic in the `toml`, then i don’t believe you can unwind.
- haberman 2y ago
  The Rust docs specifically discourage using panics as try/catch: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/fn.catch_unwind.html > It is not recommended to use this function for a general try/catch mechanism. The Result type is more appropriate to use for functions that can fail on a regular basis. Additionally, this function is not guaranteed to catch all panics, see the “Notes” section below. I think panics in Rust are intended to be unrecoverable, and catch_unwind is mainly intended to make the shutdown more orderly and possibly localized. Any data structure that paniced is probably in an unknown state that is not safe for further use.
  - brokencode 2y ago
    The situation in Rust seems to be a bit complicated. But I did find that panicking within a thread you spawn kills just that thread and not the whole program. And it seems that Tokio has the same behavior. https://github.com/tokio-rs/tokio/issues/2002#issuecomment-663886031 https://github.com/tokio-rs/tokio/issues/2002#issuecomment-6... And web frameworks like Tower provide standard ways of handling panics and turning them into error responses. https://docs.rs/tower-http/latest/tower_http/catch_panic/index.html https://docs.rs/tower-http/latest/tower_http/catch_panic/ind... So I don’t think panics are necessarily meant to be program-killing in Rust, even if Result types are heavily recommended instead.
  - Too 2y ago
    https://doc.rust-lang.org/nomicon/unwinding.html https://doc.rust-lang.org/nomicon/unwinding.html explains the philosophy and how they got there a bit further. Rust grew from a short-lived task concept, where panic of a task wouldn't be the end of the world, then it got used to write bigger applications instead and finer catch-concepts were needed.
  - J_Shelby_J 2y ago
    Catch unwind is useful when you have a dependency that for some reason panics and you can’t control it.
brokencode 2y ago
How is it knowing to panic if it isn’t checking? It seems like I am paying the cost of doing the checking either way, at least in terms of performance. So it should give me the ability to handle the error somehow. As a C# and Typescript developer primarily, this concept of killing the whole program due to a bug anywhere in any part of the code is very foreign to me. I’d expect that to only happen if you ran out of memory, had a hardware failure, or other such catastrophic error. To me, dividing by zero is a problem, but not worse than pretty much any other type of logical error that doesn’t panic.
- paulddraper 2y ago
  > killing the whole program due to a bug anywhere in any part of the code is very foreign to me. But getting the wrong answer due to a bug anywhere in any part of the code is not?
  - deleted 2y ago
    [deleted]
  - ludwik 2y ago
    Allowing you to catch and handle an exception is not the same as silently returning a wrong answer.
    - caspper69 2y ago
      It seems to me that exceptions have a bad rep. Complaints range from too slow to hidden control flow to just not liking them. I absolutely see the benefit in application code, otherwise you're error checking every function call. On the other hand, I completely understand not using such a mechanism in kernel and driver code. But Rust has decided against exceptions (which I actually believe were part of the original vision way back when, but please don't quote me), so now there's panics. Everything is a tradeoff at some level.
    - paulddraper 2y ago
      Yes, the wrong answer is terrifying

That's why you have wrappers that return Result enumerations. There is an overhead to check if an operation is valid, pay for it if you need it. This is exactly how Rust works, for example.

demurgos 2y ago

Rust's panics are recoverable, so they're more like exceptions. This means that you may need to care about "unwind" safety and values in a potentially invalid state. It's the main reason for mutex poisoning and having to deal with it when locking. Overall, I'm not entirely sure if Rust would be better or not if panics were non-recoverable. PS: For completeness, there are flags to control the panic behavior; but you can't rely on them when writing a lib.

ryang2718 2y ago
Unless a library developer decides to abort on panic in the `toml`, then i don’t believe you can unwind.
haberman 2y ago
The Rust docs specifically discourage using panics as try/catch: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/fn.catch_unwind.html > It is not recommended to use this function for a general try/catch mechanism. The Result type is more appropriate to use for functions that can fail on a regular basis. Additionally, this function is not guaranteed to catch all panics, see the “Notes” section below. I think panics in Rust are intended to be unrecoverable, and catch_unwind is mainly intended to make the shutdown more orderly and possibly localized. Any data structure that paniced is probably in an unknown state that is not safe for further use.
- brokencode 2y ago
  The situation in Rust seems to be a bit complicated. But I did find that panicking within a thread you spawn kills just that thread and not the whole program. And it seems that Tokio has the same behavior. https://github.com/tokio-rs/tokio/issues/2002#issuecomment-663886031 https://github.com/tokio-rs/tokio/issues/2002#issuecomment-6... And web frameworks like Tower provide standard ways of handling panics and turning them into error responses. https://docs.rs/tower-http/latest/tower_http/catch_panic/index.html https://docs.rs/tower-http/latest/tower_http/catch_panic/ind... So I don’t think panics are necessarily meant to be program-killing in Rust, even if Result types are heavily recommended instead.
- Too 2y ago
  https://doc.rust-lang.org/nomicon/unwinding.html https://doc.rust-lang.org/nomicon/unwinding.html explains the philosophy and how they got there a bit further. Rust grew from a short-lived task concept, where panic of a task wouldn't be the end of the world, then it got used to write bigger applications instead and finer catch-concepts were needed.
- J_Shelby_J 2y ago
  Catch unwind is useful when you have a dependency that for some reason panics and you can’t control it.

brokencode 2y ago

How is it knowing to panic if it isn’t checking? It seems like I am paying the cost of doing the checking either way, at least in terms of performance. So it should give me the ability to handle the error somehow. As a C# and Typescript developer primarily, this concept of killing the whole program due to a bug anywhere in any part of the code is very foreign to me. I’d expect that to only happen if you ran out of memory, had a hardware failure, or other such catastrophic error. To me, dividing by zero is a problem, but not worse than pretty much any other type of logical error that doesn’t panic.

paulddraper 2y ago
> killing the whole program due to a bug anywhere in any part of the code is very foreign to me. But getting the wrong answer due to a bug anywhere in any part of the code is not?
- deleted 2y ago
  [deleted]
- ludwik 2y ago
  Allowing you to catch and handle an exception is not the same as silently returning a wrong answer.
  - caspper69 2y ago
    It seems to me that exceptions have a bad rep. Complaints range from too slow to hidden control flow to just not liking them. I absolutely see the benefit in application code, otherwise you're error checking every function call. On the other hand, I completely understand not using such a mechanism in kernel and driver code. But Rust has decided against exceptions (which I actually believe were part of the original vision way back when, but please don't quote me), so now there's panics. Everything is a tradeoff at some level.
  - paulddraper 2y ago
    Yes, the wrong answer is terrifying