6 ms·

Rust made the same call. Panic isn't supposed to be "I'm not sure what to do now, maybe my caller will know?". That is an error not a panic amd you return it. A

Rust made the same call. Panic isn't supposed to be "I'm not sure what to do now, maybe my caller will know?". That is an error not a panic amd you return it. A panic is for "I just realized I or someone else did something really bad and the invariants of everything are now in question, hit the breakers, lets try this again". If your dependency library, like so many, panicked rather than take the time and effort to check the conditions that would cause an out of bounds access, then they are bad and they should feel bad, fork and merge the fix and don't say anything, they will feel the shame.

quickthrower2 3y ago
Running off forks is no fun though.
- hackerbrother 3y ago
  So the question is: should there exist a method that means “bring down the whole ship”. (Or, should that method be something more severe than “panic”, and panic should be redefined with a more limited scope.)
  - quickthrower2 3y ago
    I agree. I like C# where you can expect libraries to play nice. In theory it is possible for C# library to crash your app but it is definitely not on the trodden path. But I do prefer return values over exceptions! I have not used Go and I think the err != nil boilerplate might drive me a little insane, but Haskells option types seem a nice fit.
beltsazar 3y ago
> Rust made the same call. Completely different. In Rust when you spawn a thread [1] or an async task [2], you'll get a handle from which you can check if a panic happens inside the thread/task. Even if you ignore the handle, a panic inside a thread/task won't crash the entire program. --- [1] https://doc.rust-lang.org/std/thread/fn.spawn.html https://doc.rust-lang.org/std/thread/fn.spawn.html [2] https://docs.rs/tokio/latest/tokio/task/fn.spawn.html https://docs.rs/tokio/latest/tokio/task/fn.spawn.html
- dinosaurdynasty 3y ago
  Yeah I've been hit by this, I've setup a panic handler to purposefully kill the entire process because otherwise long-running threads die and don't restart (and it was easier to do it that way).
zoky 3y ago
> Panic isn't supposed to be "I'm not sure what to do now, maybe my caller will know?". So panic is supposed to be “I’m not sure what to do now, I don’t care if my caller knows”? No process running outside of kernel space ever has any business panicking. Throw an error and move on with your life (or don’t, that’s fine too) but don’t punish your caller by forcing it to crash because you failed to foresee X, Y, or Z circumstances.
- xyzzy_plugh 3y ago
  If it's reasonable for the caller to continue then return an error. If the state of the world is irreconcilable, panic is the right call.
  - zoky 3y ago
    And how is the called method supposed to be able to determine whether the state of the world is irreconcilable? For that matter, how is the called method supposed to determine what the state of the world even is? And why on Earth would we trust it to do so? Is encapsulation not even a thing anymore? I really just don’t understand.
    - bogeholm 3y ago
      A classic example is: - Accessing array out of bounds: panic - File not found: error
      - nishs 3y ago
        There are two "kinds" of panics: those initiated by the Go runtime, and those initiated by the program author, though technically there isn't a distinction. When you access an array out of bounds, the Go runtime initiates the panic. On the other hand, for a condition that the program should hold but doesn't, the program author should initiate the panic. For example, in the exhaustive switch below, reaching the default case means that either you have somehow incorrectly allowed the construction of an invalid token value earlier in your program, or you have missed to account for a valid token value in this function. func (t token) symbol() byte { switch t { case add: return '+' case sub: return '-' case mul: return '*' case quo: return '/' default: panic("unknown token") } } Errors are different. For example, url.Parse returns an error if its input string is an invalidly formatted URL. package url func Parse(rawURL string) (*URL, error)
masklinn 3y ago
> Rust made the same call. It did not though? - threads implicitly catch_panic at their boundary, and convert that to a `Result` which you can receive when you join on the thread: https://doc.rust-lang.org/std/thread/type.Result.html https://doc.rust-lang.org/std/thread/type.Result.html - in theory an async runtime could shut down on panic, but tokio at least does not, much like `std::thread::spawn` it'll catch_panic and return a JoinError to however is await-ing the joinhandle: https://docs.rs/tokio/latest/tokio/task/struct.JoinError.html https://docs.rs/tokio/latest/tokio/task/struct.JoinError.htm... If you drop the handles, the error just is not signaled: - sync: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b20cc7c1af5ca42485e83820b1c1e56f https://play.rust-lang.org/?version=stable&mode=debug&editio... - async (tokio): https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=25f424fd6ce6f463d28508633741626c https://play.rust-lang.org/?version=stable&mode=debug&editio...
- galangalalgol 3y ago
  Yeah I think I remember that being a controversial decision when it was made for threads? One of the valid reasons for a panic is that you've encountered something that makes you think your adress space is in a bad state. Threads share an address space, so the reasoning was that if they panic, so should the process, but that isn't what happened.
DangitBobby 3y ago
Then why does recover() even exist? Programs seem to continue just fine after a recover.

quickthrower2 3y ago

Running off forks is no fun though.

hackerbrother 3y ago
So the question is: should there exist a method that means “bring down the whole ship”. (Or, should that method be something more severe than “panic”, and panic should be redefined with a more limited scope.)
- quickthrower2 3y ago
  I agree. I like C# where you can expect libraries to play nice. In theory it is possible for C# library to crash your app but it is definitely not on the trodden path. But I do prefer return values over exceptions! I have not used Go and I think the err != nil boilerplate might drive me a little insane, but Haskells option types seem a nice fit.

beltsazar 3y ago

> Rust made the same call. Completely different. In Rust when you spawn a thread [1] or an async task [2], you'll get a handle from which you can check if a panic happens inside the thread/task. Even if you ignore the handle, a panic inside a thread/task won't crash the entire program. --- [1] https://doc.rust-lang.org/std/thread/fn.spawn.html https://doc.rust-lang.org/std/thread/fn.spawn.html [2] https://docs.rs/tokio/latest/tokio/task/fn.spawn.html https://docs.rs/tokio/latest/tokio/task/fn.spawn.html

dinosaurdynasty 3y ago
Yeah I've been hit by this, I've setup a panic handler to purposefully kill the entire process because otherwise long-running threads die and don't restart (and it was easier to do it that way).

zoky 3y ago

> Panic isn't supposed to be "I'm not sure what to do now, maybe my caller will know?". So panic is supposed to be “I’m not sure what to do now, I don’t care if my caller knows”? No process running outside of kernel space ever has any business panicking. Throw an error and move on with your life (or don’t, that’s fine too) but don’t punish your caller by forcing it to crash because you failed to foresee X, Y, or Z circumstances.

xyzzy_plugh 3y ago
If it's reasonable for the caller to continue then return an error. If the state of the world is irreconcilable, panic is the right call.
- zoky 3y ago
  And how is the called method supposed to be able to determine whether the state of the world is irreconcilable? For that matter, how is the called method supposed to determine what the state of the world even is? And why on Earth would we trust it to do so? Is encapsulation not even a thing anymore? I really just don’t understand.
  - bogeholm 3y ago
    A classic example is: - Accessing array out of bounds: panic - File not found: error
    - nishs 3y ago
      There are two "kinds" of panics: those initiated by the Go runtime, and those initiated by the program author, though technically there isn't a distinction. When you access an array out of bounds, the Go runtime initiates the panic. On the other hand, for a condition that the program should hold but doesn't, the program author should initiate the panic. For example, in the exhaustive switch below, reaching the default case means that either you have somehow incorrectly allowed the construction of an invalid token value earlier in your program, or you have missed to account for a valid token value in this function. func (t token) symbol() byte { switch t { case add: return '+' case sub: return '-' case mul: return '*' case quo: return '/' default: panic("unknown token") } } Errors are different. For example, url.Parse returns an error if its input string is an invalidly formatted URL. package url func Parse(rawURL string) (*URL, error)

masklinn 3y ago

> Rust made the same call. It did not though? - threads implicitly catch_panic at their boundary, and convert that to a `Result` which you can receive when you join on the thread: https://doc.rust-lang.org/std/thread/type.Result.html https://doc.rust-lang.org/std/thread/type.Result.html - in theory an async runtime could shut down on panic, but tokio at least does not, much like `std::thread::spawn` it'll catch_panic and return a JoinError to however is await-ing the joinhandle: https://docs.rs/tokio/latest/tokio/task/struct.JoinError.html https://docs.rs/tokio/latest/tokio/task/struct.JoinError.htm... If you drop the handles, the error just is not signaled: - sync: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b20cc7c1af5ca42485e83820b1c1e56f https://play.rust-lang.org/?version=stable&mode=debug&editio... - async (tokio): https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=25f424fd6ce6f463d28508633741626c https://play.rust-lang.org/?version=stable&mode=debug&editio...

galangalalgol 3y ago
Yeah I think I remember that being a controversial decision when it was made for threads? One of the valid reasons for a panic is that you've encountered something that makes you think your adress space is in a bad state. Threads share an address space, so the reasoning was that if they panic, so should the process, but that isn't what happened.

DangitBobby 3y ago

Then why does recover() even exist? Programs seem to continue just fine after a recover.