4 ms·

Exceptions are already in the language: panic/recover. Though discouraged, you can't assume they won't happen. To me, this seems like the "worst of both world

Exceptions are already in the language: panic/recover. Though discouraged, you can't assume they won't happen. To me, this seems like the "worst of both worlds". It doesn't feel like a final position to me, it feels like a 1.0 position.

tptacek 13y ago
You can abuse "panic" to implement exceptions in Golang the way you can abuse "longjmp" to do that in C. The purpose of "panic" isn't for general-purpose exceptions. It's to panic the program.
- justinsb 13y ago
  It's clear you shouldn't throw. But correct code must assume that any function you call might throw; which is why you should use defer blocks e.g. to release resources, instead of C-style "cleanup at the bottom of the function". (Defer is also prettier IMHO)
  - tptacek 13y ago
    You're not "throwing". You're "panicking".
    - ithkuil 13y ago
      Or raising? That's just terminology. The behaviors of c++/java/python exceptions and Go panics are similar regardless of the name the keyword has in those language: The execution is suspended, the stack unwound until the first handler, the handler has access to a value that is "thrown". Stack information is preserved in order to print meaningful stack traces. C++/java/python have syntax sugar that performs a pattern match on the thrown object to decide whether to handle it or bubble it up, while in Go you do it manually, but other that that I don't see much of a difference in the mechanics of them to justify being so pedantic about the naming of the action.
  - JulianMorrison 13y ago
    It's idiomatically correct to ignore panics and let them take the whole program down with a crash. A panic indicates that your program is already doing extremely incorrect things. Rare is the program where picking itself up and continuing a possible Sorcerer's Apprentice mode rampage is better than just stopping and telling you what needs fixing.
- mjibson 13y ago
  Note that this mechanic is used in the golang standard library and works great as a catchall: http://golang.org/src/pkg/text/template/exec.go#L93 http://golang.org/src/pkg/text/template/exec.go#L93
mratzloff 13y ago
But panics are not exceptions. They should not be used like exceptions, and there is no "hierarchy of panic types". They are used for things like out of bounds indexes, where in C it would simply be a segfault. A panic is a way of gracefully exiting a program that would have segfaulted otherwise. Correct code should check for out of bound indexes either way.
- justinsb 13y ago
  I think I've answered this elsewhere: the issue for me is that you have to handle exceptions _and_ error codes. Though you raise an interesting point: Should you check array indexes if the runtime is also checking it for you? In Java, the runtime is guaranteed to throw an exception and it is relatively rare that you would pre-check the array indexes (you might use assertions in debug code). Incidentally, array bounds checking is actually relatively expensive, to the point where most JVMs (which use signed indexes) use an unsigned comparison trick to make it one comparison instead of two. So it does matter...
  - redbad 13y ago
    If you're recovering from panics, in general, you're doing something wrong.
  - enneff 13y ago
    > the issue for me is that you have to handle exceptions _and_ error codes. Except you don't. I haven't used recover in any of my code for a long time (more than a year). Most of the time you don't need to worry about handling panics, but you can if you really need to. > Should you check array indexes if the runtime is also checking it for you? In Go the generated code does it. You shouldn't do it yourself.
    - justinsb 13y ago
      I consider defer to be part of handling exceptions, but I can see how we differ here. We're seriously drifting off track here, but if we should rely on Go to check array indexes, that seems like you _would_ want a recover block, so that we can map it to a Go-preferred error code?
joncooper 13y ago
The point is that an exception in Go world means: something which should not ever happen, and which renders continued execution impossible. IMO recover should only be used to wind down execution in as graceful a manner a possible prior to terminating the program. As opposed to an error, which can and will happen.
- aaronblohowiak 13y ago
  we should rename recover to "log this before terminating the process"

tptacek 13y ago

You can abuse "panic" to implement exceptions in Golang the way you can abuse "longjmp" to do that in C. The purpose of "panic" isn't for general-purpose exceptions. It's to panic the program.

justinsb 13y ago
It's clear you shouldn't throw. But correct code must assume that any function you call might throw; which is why you should use defer blocks e.g. to release resources, instead of C-style "cleanup at the bottom of the function". (Defer is also prettier IMHO)
- tptacek 13y ago
  You're not "throwing". You're "panicking".
  - ithkuil 13y ago
    Or raising? That's just terminology. The behaviors of c++/java/python exceptions and Go panics are similar regardless of the name the keyword has in those language: The execution is suspended, the stack unwound until the first handler, the handler has access to a value that is "thrown". Stack information is preserved in order to print meaningful stack traces. C++/java/python have syntax sugar that performs a pattern match on the thrown object to decide whether to handle it or bubble it up, while in Go you do it manually, but other that that I don't see much of a difference in the mechanics of them to justify being so pedantic about the naming of the action.
- JulianMorrison 13y ago
  It's idiomatically correct to ignore panics and let them take the whole program down with a crash. A panic indicates that your program is already doing extremely incorrect things. Rare is the program where picking itself up and continuing a possible Sorcerer's Apprentice mode rampage is better than just stopping and telling you what needs fixing.
mjibson 13y ago
Note that this mechanic is used in the golang standard library and works great as a catchall: http://golang.org/src/pkg/text/template/exec.go#L93 http://golang.org/src/pkg/text/template/exec.go#L93

mratzloff 13y ago

But panics are not exceptions. They should not be used like exceptions, and there is no "hierarchy of panic types". They are used for things like out of bounds indexes, where in C it would simply be a segfault. A panic is a way of gracefully exiting a program that would have segfaulted otherwise. Correct code should check for out of bound indexes either way.

justinsb 13y ago
I think I've answered this elsewhere: the issue for me is that you have to handle exceptions _and_ error codes. Though you raise an interesting point: Should you check array indexes if the runtime is also checking it for you? In Java, the runtime is guaranteed to throw an exception and it is relatively rare that you would pre-check the array indexes (you might use assertions in debug code). Incidentally, array bounds checking is actually relatively expensive, to the point where most JVMs (which use signed indexes) use an unsigned comparison trick to make it one comparison instead of two. So it does matter...
- redbad 13y ago
  If you're recovering from panics, in general, you're doing something wrong.
- enneff 13y ago
  > the issue for me is that you have to handle exceptions _and_ error codes. Except you don't. I haven't used recover in any of my code for a long time (more than a year). Most of the time you don't need to worry about handling panics, but you can if you really need to. > Should you check array indexes if the runtime is also checking it for you? In Go the generated code does it. You shouldn't do it yourself.
  - justinsb 13y ago
    I consider defer to be part of handling exceptions, but I can see how we differ here. We're seriously drifting off track here, but if we should rely on Go to check array indexes, that seems like you _would_ want a recover block, so that we can map it to a Go-preferred error code?

joncooper 13y ago

The point is that an exception in Go world means: something which should not ever happen, and which renders continued execution impossible. IMO recover should only be used to wind down execution in as graceful a manner a possible prior to terminating the program. As opposed to an error, which can and will happen.

aaronblohowiak 13y ago
we should rename recover to "log this before terminating the process"