3 ms·

In most software there's no such thing as unrecoverable panic. OOM is probably the only such error, and even then it doesn't come from within your app. For all

by troupo 2y ago

In most software there's no such thing as unrecoverable panic. OOM is probably the only such error, and even then it doesn't come from within your app. For all "unrecoverable panics" you usually want to see the reason, log it, kill the offending process, clean up resources, and then usually restart the offending process. And that's the reason both Go and Rust ended up reverting their stance on "unrecoverable panics kill your program" and introduced ways to recover from them.

Ferret7446 2y ago
Go never had a stance on "unrecoverable panics kill your program". Go always supported recover, but encourages (correctly IMO) error values because they are more performant and easier to understand. The Go standard library even uses panic/recover (aka throw/catch) style programming in specific instances.
- troupo 2y ago
  > they are more performant and easier to understand. They are more performant because Go decided to make them so. E.g. in Erlang crashing a process is an expected lightweight operation. As for "easier to understand"... They are not when: - your code is littered with `x, err = ...; if err != nil` - it's not easier to understand when the code errors have to be dealt with on a higher/different level. The calling code isn't always the one that needs to deal with all the errors Just a very random example (I literally just clicked through random files): https://github.com/kubernetes/kubernetes/blob/master/pkg/controlplane/controller/clusterauthenticationtrust/cluster_authentication_trust_controller.go#L143 https://github.com/kubernetes/kubernetes/blob/master/pkg/con... Oh, look, you can't even see the logic behind all the `if err`s which do nothing but return the error to be handled elsewhere.
  - zmgsabst 2y ago
    I always liked Erlangs “crash until someone knows how to recover”.
  - CharlieDigital 2y ago
    You aren't kidding. Line 143 - 182... You'd think they'd come up with a short form for something that gets written so often.
    - skywhopper 2y ago
      They haven’t, because it’s perfectly legible, versus languages that hide control flow with implicit assumptions. The main point of Go was to avoid magic. If you don’t care for it, that’s fine. Plenty of us prefer explicit control flow.
      - williamdclt 2y ago
        Everyone prefers explicit control flows. But there's other things in the balance (noise, code density, readability), and many people think that this is pretty bad trade-off. Rust with Optionals strikes a much nicer trade-off, and personally I'd love to see a language that offers a good checked exception mechanism which would offer a lot of explicitness with most noise removed.
      - CharlieDigital 2y ago
        How about a simple one liner like (just throwing out random ideas; I'm sure these are not idiomatic) return when err return if err return ?> err return ? err Still readable, still pretty explicit IMO.
        vbezhenar 2y ago
        `return err` is a terrible approach. You must wrap the error with new error, include file and line information, so stacktrace is actually useful. When program spews some random garbage into its stderr and you have no idea where that message came from (imagine looking through millions of lines of kubernetes implementation), that's the good way to ensure that nobody would even care to look at it. Thousands of unsolved issues in kubernetes tracker is a perfect demonstration of it. Go is just bad at handling errors. Exceptions are superior in every way.
shric 2y ago
For me an unrecoverable error is when my program gets into an unexpected state. Given that I didn't anticipate such a thing ever happening, I can no longer reason about what the program will do, so the only sensible course of action is to crash immediately.
bilekas 2y ago
I have to add the obligatory “you’ve solved the halting problem” question here.
- troupo 2y ago
  No idea what this has to do with the halting problem
  - bilekas 2y ago
    > In most software there's no such thing as unrecoverable panic > The halting problem is the problem of determining, from a description of an arbitrary computer program and an input, whether the program will finish running They’re very much related to determining you’re gonna panic or not.
usrbinbash 2y ago
> In most software there's no such thing as unrecoverable panic Webserver wants to start, binding port 443/80 isn't possible because another process holds that port. Logging service wants to write to disk. The IO operation fails. RDBMS want's to access the persistent storage, the syscall fails due to insufficient permissions. How are any of those recoverable?
- troupo 2y ago
  Note how none of these issues should cause the respective programs to crash, as this is what `panic` does. They try to start, cannot do a specific operation, and they do an orderly shutdown. Or they should
  - usrbinbash 2y ago
    > and they do an orderly shutdown. Or they should Which is exactly what panic does.
    - troupo 2y ago
      --- start quote --- Panic is a built-in function that stops the ordinary flow of control and begins panicking... The process continues up the stack until all functions in the current goroutine have returned, at which point the program crashes. --- end quote --- This is far from orderly. For example, what happens to other goroutines? I also like how golang docs literally describe using panics as poor man's exceptions: --- start quote --- For a real-world example of panic and recover, see the json package from the Go standard library. It encodes an interface with a set of recursive functions. If an error occurs when traversing the value, panic is called to unwind the stack to the top-level function call, which recovers from the panic and returns an appropriate error value ... The convention in the Go libraries is that even when a package uses panic internally, its external API still presents explicit error return values. --- end quote ---
      - usrbinbash 2y ago
        > I also like how golang docs literally describe using panics as poor man's exceptions: And I like how https://github.com/golang/go/issues/26799 https://github.com/golang/go/issues/26799 describes that use of panic in the original version of this bog entry from 2010: quote: However, this is a poor example and a misuse of panic and recover as exceptions. See https://golang.org/doc/effective_go.html#panic https://golang.org/doc/effective_go.html#panic The example will be invalid soon with the release of go 1.11 as well. The panic/recover was removed from the unmarshal code. See master's end quote. The blog entry was later changed because this was fixed. It now refers to marshaling which, sadly, sill uses this mechanism. The fact that this is still in the json package is a pain point, yes. Does it validate the use of panic as a form of flow control? No. Here is what "Effective Go" has to say about the topic: https://go.dev/doc/effective_go#panic https://go.dev/doc/effective_go#panic quote: But what if the error is unrecoverable? Sometimes the program simply cannot continue. For this purpose, there is a built-in function panic that in effect creates a run-time error that will stop the program (but see the next section). end quote.

by troupo 2y ago

Ferret7446 2y ago

Go never had a stance on "unrecoverable panics kill your program". Go always supported recover, but encourages (correctly IMO) error values because they are more performant and easier to understand. The Go standard library even uses panic/recover (aka throw/catch) style programming in specific instances.

troupo 2y ago
> they are more performant and easier to understand. They are more performant because Go decided to make them so. E.g. in Erlang crashing a process is an expected lightweight operation. As for "easier to understand"... They are not when: - your code is littered with `x, err = ...; if err != nil` - it's not easier to understand when the code errors have to be dealt with on a higher/different level. The calling code isn't always the one that needs to deal with all the errors Just a very random example (I literally just clicked through random files): https://github.com/kubernetes/kubernetes/blob/master/pkg/controlplane/controller/clusterauthenticationtrust/cluster_authentication_trust_controller.go#L143 https://github.com/kubernetes/kubernetes/blob/master/pkg/con... Oh, look, you can't even see the logic behind all the `if err`s which do nothing but return the error to be handled elsewhere.
- zmgsabst 2y ago
  I always liked Erlangs “crash until someone knows how to recover”.
- CharlieDigital 2y ago
  You aren't kidding. Line 143 - 182... You'd think they'd come up with a short form for something that gets written so often.
  - skywhopper 2y ago
    They haven’t, because it’s perfectly legible, versus languages that hide control flow with implicit assumptions. The main point of Go was to avoid magic. If you don’t care for it, that’s fine. Plenty of us prefer explicit control flow.
    - williamdclt 2y ago
      Everyone prefers explicit control flows. But there's other things in the balance (noise, code density, readability), and many people think that this is pretty bad trade-off. Rust with Optionals strikes a much nicer trade-off, and personally I'd love to see a language that offers a good checked exception mechanism which would offer a lot of explicitness with most noise removed.
    - CharlieDigital 2y ago
      How about a simple one liner like (just throwing out random ideas; I'm sure these are not idiomatic) return when err return if err return ?> err return ? err Still readable, still pretty explicit IMO.
      - vbezhenar 2y ago
        `return err` is a terrible approach. You must wrap the error with new error, include file and line information, so stacktrace is actually useful. When program spews some random garbage into its stderr and you have no idea where that message came from (imagine looking through millions of lines of kubernetes implementation), that's the good way to ensure that nobody would even care to look at it. Thousands of unsolved issues in kubernetes tracker is a perfect demonstration of it. Go is just bad at handling errors. Exceptions are superior in every way.

shric 2y ago

For me an unrecoverable error is when my program gets into an unexpected state. Given that I didn't anticipate such a thing ever happening, I can no longer reason about what the program will do, so the only sensible course of action is to crash immediately.

bilekas 2y ago

I have to add the obligatory “you’ve solved the halting problem” question here.

troupo 2y ago
No idea what this has to do with the halting problem
- bilekas 2y ago
  > In most software there's no such thing as unrecoverable panic > The halting problem is the problem of determining, from a description of an arbitrary computer program and an input, whether the program will finish running They’re very much related to determining you’re gonna panic or not.

usrbinbash 2y ago

> In most software there's no such thing as unrecoverable panic Webserver wants to start, binding port 443/80 isn't possible because another process holds that port. Logging service wants to write to disk. The IO operation fails. RDBMS want's to access the persistent storage, the syscall fails due to insufficient permissions. How are any of those recoverable?

troupo 2y ago
Note how none of these issues should cause the respective programs to crash, as this is what `panic` does. They try to start, cannot do a specific operation, and they do an orderly shutdown. Or they should
- usrbinbash 2y ago
  > and they do an orderly shutdown. Or they should Which is exactly what panic does.
  - troupo 2y ago
    --- start quote --- Panic is a built-in function that stops the ordinary flow of control and begins panicking... The process continues up the stack until all functions in the current goroutine have returned, at which point the program crashes. --- end quote --- This is far from orderly. For example, what happens to other goroutines? I also like how golang docs literally describe using panics as poor man's exceptions: --- start quote --- For a real-world example of panic and recover, see the json package from the Go standard library. It encodes an interface with a set of recursive functions. If an error occurs when traversing the value, panic is called to unwind the stack to the top-level function call, which recovers from the panic and returns an appropriate error value ... The convention in the Go libraries is that even when a package uses panic internally, its external API still presents explicit error return values. --- end quote ---
    - usrbinbash 2y ago
      > I also like how golang docs literally describe using panics as poor man's exceptions: And I like how https://github.com/golang/go/issues/26799 https://github.com/golang/go/issues/26799 describes that use of panic in the original version of this bog entry from 2010: quote: However, this is a poor example and a misuse of panic and recover as exceptions. See https://golang.org/doc/effective_go.html#panic https://golang.org/doc/effective_go.html#panic The example will be invalid soon with the release of go 1.11 as well. The panic/recover was removed from the unmarshal code. See master's end quote. The blog entry was later changed because this was fixed. It now refers to marshaling which, sadly, sill uses this mechanism. The fact that this is still in the json package is a pain point, yes. Does it validate the use of panic as a form of flow control? No. Here is what "Effective Go" has to say about the topic: https://go.dev/doc/effective_go#panic https://go.dev/doc/effective_go#panic quote: But what if the error is unrecoverable? Sometimes the program simply cannot continue. For this purpose, there is a built-in function panic that in effect creates a run-time error that will stop the program (but see the next section). end quote.