3 ms·

One major difference between panic and exceptions is that you can only catch it on a function exit boundary with defer and recover. There is no "try". So reall

One major difference between panic and exceptions is that you can only catch it on a function exit boundary with defer and recover. There is no "try". So really, you should think of panics more like Erlang's error handling, where a segment of the program (bounded by "recover") will just stop running, but can initiate the process of self repair.

pcwalton 13y ago
The difference is that Erlang has process isolation: a panic is guaranteed not to mess up the state of any other process, because there is no shared state. This is what makes reliable self-repair possible. In Go, there is one giant shared mutable heap shared between all goroutines. So there is no guarantee that a panicked goroutine left the heap in an orderly state such that self-repair is possible. Erlang actors and goroutines are very very different.
- JulianMorrison 13y ago
  True. Although, panics do run defers, so with good coding practise it's possible to ensure that either you don't share things (but rather pass them around over channels) or things like locks are safely cleaned up.
  - masklinn 13y ago
    > with good coding practise it's possible to ensure that either you don't share things So is it in C, that's no argument.
    - JulianMorrison 13y ago
      Turing completeness, your argument is invalid. But seriously, it's not just possible to be memory safe in Go, it's fairly easy. You basically have to remember to never lock without defer mutex.Unlock() unless it can't possibly panic, and to share data via channels such that it only ever has a unique "owner". Personally I'd have much preferred full isolation, immutable data with threadsafe mutable references, and Clojure style "persistent" collections which can be treated as values. But Go didn't go down that route.
      - Locke1689 13y ago
        "All you have to do is call free with every malloc and always keep track of your array size. Geez, people, it's not that hard!"

pcwalton 13y ago

The difference is that Erlang has process isolation: a panic is guaranteed not to mess up the state of any other process, because there is no shared state. This is what makes reliable self-repair possible. In Go, there is one giant shared mutable heap shared between all goroutines. So there is no guarantee that a panicked goroutine left the heap in an orderly state such that self-repair is possible. Erlang actors and goroutines are very very different.

JulianMorrison 13y ago
True. Although, panics do run defers, so with good coding practise it's possible to ensure that either you don't share things (but rather pass them around over channels) or things like locks are safely cleaned up.
- masklinn 13y ago
  > with good coding practise it's possible to ensure that either you don't share things So is it in C, that's no argument.
  - JulianMorrison 13y ago
    Turing completeness, your argument is invalid. But seriously, it's not just possible to be memory safe in Go, it's fairly easy. You basically have to remember to never lock without defer mutex.Unlock() unless it can't possibly panic, and to share data via channels such that it only ever has a unique "owner". Personally I'd have much preferred full isolation, immutable data with threadsafe mutable references, and Clojure style "persistent" collections which can be treated as values. But Go didn't go down that route.
    - Locke1689 13y ago
      "All you have to do is call free with every malloc and always keep track of your array size. Geez, people, it's not that hard!"