5 ms·

No, think of panic() as unhandled Segmentation Fault (and other Go specific unrecoverable errors). You can handle Segmentation Fault, but you need to know what

No, think of panic() as unhandled Segmentation Fault (and other Go specific unrecoverable errors). You can handle Segmentation Fault, but you need to know what you are doing. In Go it's the same.

quotemstr 9y ago
Panic is _semantically_ the same as throw. That Go culture treats panic like evil voodoo doesn't change how the language construct works.
- PopsiclePete 9y ago
  Nobody in Go culture treats it as "evil voodoo" that I'm aware of. There are clear guide-lines. User passes in a path to a file that doesn't exist and you attempt to open it? Return an error. That's not "exceptional" or "programmer error" - it's just normal "shit happens". You have an array-like structure with 10 elements and your function that modifies it gets passed in index 13? That's probably a bug or programmer error, not "user" error - so panic. Go documentation is very clear on the difference between the two, actually. I've never been confused.
jcelerier 9y ago
But panic is recoverable in go, with "recover()". That's literally the same mechanism than exceptions with a different syntax and keywords.
- deleted 9y ago
  [deleted]
- krylon 9y ago
  Strictly speaking, a) you can catch a segfault, too, by installing a signal handler, and b) recover() is not quite the same, because with "real" exceptions, you can state in a catch clause what types of exceptions you handle, and the compiler/runtime will do the right thing, where in Go, you call recover() and look at the return value to see if there is something you can do about it. And if not, I do not think you can even "re-throw" the panic further up the stack. (I think the panic()/recover() mechanism is intentionally crude in order to discourage people from over- or abusing it.)
  - pjmlp 9y ago
    > a) you can catch a segfault, too, by installing a signal handler, My POSIX knowledge is a bit out of date, but if I remember correctly what actually happens is not guaranteed to work across all UNIXes.
    - jhasse 9y ago
      Good luck getting a fully C++14 compatible compiler with exceptions working on all UNIXes.
      - pjmlp 9y ago
        So far I haven't had any relevant problem regarding C++ exceptions regardless of the language level. Besides, signals are OS specific, while C++ exceptions are compiler specific.
      - jcelerier 9y ago
        > all UNIXes. what do you put in "all UNIXes" ? Xenix 1.0 ? MULTICS? Because all current unices (https://upload.wikimedia.org/wikipedia/commons/7/77/Unix_history-simple.svg https://upload.wikimedia.org/wikipedia/commons/7/77/Unix_his...) would have no problem running recent GCC and C++ exceptions. I mean, for hell's sake, C++ exceptions date back to 1990. Nowadays you can throw exceptions on damn 16-bit microcontrollers (https://en.wikipedia.org/wiki/TI_MSP430 https://en.wikipedia.org/wiki/TI_MSP430) ; I doubt there's a relevant, non legacy unix where this does not work.

No, think of panic() as unhandled Segmentation Fault (and other Go specific unrecoverable errors). You can handle Segmentation Fault, but you need to know what you are doing. In Go it's the same.

quotemstr 9y ago

Panic is _semantically_ the same as throw. That Go culture treats panic like evil voodoo doesn't change how the language construct works.

PopsiclePete 9y ago
Nobody in Go culture treats it as "evil voodoo" that I'm aware of. There are clear guide-lines. User passes in a path to a file that doesn't exist and you attempt to open it? Return an error. That's not "exceptional" or "programmer error" - it's just normal "shit happens". You have an array-like structure with 10 elements and your function that modifies it gets passed in index 13? That's probably a bug or programmer error, not "user" error - so panic. Go documentation is very clear on the difference between the two, actually. I've never been confused.

jcelerier 9y ago

But panic is recoverable in go, with "recover()". That's literally the same mechanism than exceptions with a different syntax and keywords.

deleted 9y ago
[deleted]
krylon 9y ago
Strictly speaking, a) you can catch a segfault, too, by installing a signal handler, and b) recover() is not quite the same, because with "real" exceptions, you can state in a catch clause what types of exceptions you handle, and the compiler/runtime will do the right thing, where in Go, you call recover() and look at the return value to see if there is something you can do about it. And if not, I do not think you can even "re-throw" the panic further up the stack. (I think the panic()/recover() mechanism is intentionally crude in order to discourage people from over- or abusing it.)
- pjmlp 9y ago
  > a) you can catch a segfault, too, by installing a signal handler, My POSIX knowledge is a bit out of date, but if I remember correctly what actually happens is not guaranteed to work across all UNIXes.
  - jhasse 9y ago
    Good luck getting a fully C++14 compatible compiler with exceptions working on all UNIXes.
    - pjmlp 9y ago
      So far I haven't had any relevant problem regarding C++ exceptions regardless of the language level. Besides, signals are OS specific, while C++ exceptions are compiler specific.
    - jcelerier 9y ago
      > all UNIXes. what do you put in "all UNIXes" ? Xenix 1.0 ? MULTICS? Because all current unices (https://upload.wikimedia.org/wikipedia/commons/7/77/Unix_history-simple.svg https://upload.wikimedia.org/wikipedia/commons/7/77/Unix_his...) would have no problem running recent GCC and C++ exceptions. I mean, for hell's sake, C++ exceptions date back to 1990. Nowadays you can throw exceptions on damn 16-bit microcontrollers (https://en.wikipedia.org/wiki/TI_MSP430 https://en.wikipedia.org/wiki/TI_MSP430) ; I doubt there's a relevant, non legacy unix where this does not work.