5 ms·

No, you don't. You should never be using recover as a matter of course. You seem really hung-up on this point. Can you link to some code that illustrates your

by redbad 13y ago

No, you don't. You should never be using recover as a matter of course. You seem really hung-up on this point. Can you link to some code that illustrates your concerns?

burntsushi 13y ago
That's just not true. There are very useful idioms for panic/recover, like when your code is profligate with errors (parsing, database work, etc.) It's even used in the standard library: http://golang.org/src/pkg/text/template/exec.go#L93 http://golang.org/src/pkg/text/template/exec.go#L93 (I use the pattern myself in certain situations. It's extremely useful.)
- redbad 13y ago
  Note I said "as a matter of course". I agree it's useful in certain very limited circumstances, like parsing. But certainly not database work, unless you have a very different idea of what that entails than I do. Link to code?
  - burntsushi 13y ago
    It's the same principle as parsing. Database work involves lots of querying, scanning, etc. All of these operations produce errors. In the work that I do, the response to an error is usually, "rollback, show error to user." This makes it ideal for panic/recover. (And this can work well for either command line applications or web applications.)
    - vertex-four 13y ago
      Panicking isn't done when a database operation fails. Returning an error value is. It's just like old-school C. Panics are for programming errors or things like out of memory conditions, not errors in ordinary operation, even when components are failing.
      - burntsushi 13y ago
        I hate to be rude, but I feel like you jumped into this thread without reading the context. I'm not talking about panicing instead of returning errors. I'm talking about using an idiom---which is used in the Go standard library (see my link up-thread)---to make error handling more terse when you're working with code that is otherwise profligate with checking errors. At no point is a panic exposed to the user of a program or to the client of a library. At no point are errors ignored. The panics are kept within package and converted to error values.
        redbad 13y ago
        Guarding your library boundary with a recover doesn't absolve your library internals from being nonidiomatic by using panics. (That the stdlib uses panic/recover in a few specific places does not make it broadly idiomatic.) Without seeing specific code I can't say for sure, but it's very unlikely that any database interaction code is best modeled with panic/recover for error handling. I'm very curious to see the source, at this point.
        burntsushi 13y ago
        > Guarding your library boundary with a recover doesn't absolve your library internals from being nonidiomatic by using panics. Using panic/recover doesn't automatically make your code nonidiomatic. > (That the stdlib uses panic/recover in a few specific places does not make it broadly idiomatic.) That the stdlib uses panic/recover in several places is a good indicator that "never use panic/recover" is bad advice. Note that while I agree that just because something is in the stdlib doesn't mean it's idiomatic, I also cite that this particular approach is used to make the structure and organization of code more clear. Since it's used in several packages, I claim that this is a strong hint that panic/recover is appropriate in limited scenarios. > Without seeing specific code I can't say for sure, but it's very unlikely that any database interaction code is best modeled with panic/recover for error handling. I'm very curious to see the source, at this point. It's really not that hard to imagine. For example: http://play.golang.org/p/fhpRLd8EHY http://play.golang.org/p/fhpRLd8EHY We seem to have some wires crossed. Let's be clear, shall we? * The panic/recover idiom is rarely used, but it is an idiom. * There are trade-offs involved with using panic/recover. In my sample linked in this comment, many of the functions in database/sql need to be stubbed out so that they panic. However, the cost of this is relatively small, since it can mostly be isolated in a package. * The idiom is most frequently seen in parsing because there are a lot of error cases to handle and the response to each error is typically the same. * While parsing is the common scenario, I claim it is not the only one. I cite that database work is profligate with error checking, and depending on your application, there's a reasonable chance that the response to each error is going to be the same. When doing a lot of it, it can pay off to use the panic/recover idiom with similar benefits as for doing it with parsing. * There may well be other scenarios where such handling is appropriate, but I have not come across them. I've done an unusual amount of work with parsers and have done some database work, so I've had the opportunity to bump up against the panic/recover idiom a bit more than normal. As with anything else, it can be abused. But I find it extraordinarily useful in certain situations.
    - waps 13y ago
      This is just another example of Go's fundamental attitude. Stuff is available for the language designers, but not for you : * generic functions (e.g. append) * generic data types (e.g. slices) * exceptions (like illustrated above) * special case syntax * Custom event loops * precompiler macros (very bad to use, horrible, blah blah ... except of course for the people imposing this restriction, and YES they're using it amongst other things to workaround the lack of generics in C) ... This attitude was common in middle-90s "generic" programming languages like Ocaml, Modula-2 and others. You should simply look at Go as one of those languages and treat it as such. If this attitude bothers you, you should look at C++0x and D.
      - burntsushi 13y ago
        I've read your comment twice and I cannot see any pertinent connection between it and what I said.
justinsb 13y ago
Agreed, you should be using defer, not recover. The canonical examples are closing a file and releasing a mutex. Both have code samples here: http://blog.golang.org/defer-panic-and-recover http://blog.golang.org/defer-panic-and-recover I'm confused as to what you guys are saying: are you saying that you don't need to handle exceptions (whether using defer or recover), or that it's better to use defer over recover? I take exception to the former, totally agree with the latter.
- redbad 13y ago
  defer and recover have nothing to do with each other, except that in the few circumstances where it's appropriate to use recover, you often do it within a defer block. > are you saying that you don't need to handle exceptions > (whether using defer or recover) Go doesn't have exceptions. You don't need to handle (i.e. explicitly deal with) panics via recover. If you do, especially if you're not making the panics yourself in e.g. a parsing package, that's a bad code smell and you're probably doing something wrong.
- enneff 13y ago
  defer doesn't "handle" panics. It won't stop your program from crashing. You have serious gaps in your knowledge on this subject.
  - justinsb 13y ago
    My understanding is that defer is the broad equivalent of a Java finally block, and recover is the broad equivalent of a Java catch block. I think of both as ways of handling exceptions, although I see how the word "handle" could be interpreted in a way that makes my statements nonsensical. By handling I meant "doing the right thing", not "swallowing the panic/exception"; I apologize for the ambiguity you found. If you do still think I have gaps in my knowledge, I humbly suggest that you briefly fill in those gaps with facts; it should save you time in the long run and will likely win you a few converts!
    - enneff 13y ago

by redbad 13y ago

No, you don't. You should never be using recover as a matter of course. You seem really hung-up on this point. Can you link to some code that illustrates your concerns?

burntsushi 13y ago

That's just not true. There are very useful idioms for panic/recover, like when your code is profligate with errors (parsing, database work, etc.) It's even used in the standard library: http://golang.org/src/pkg/text/template/exec.go#L93 http://golang.org/src/pkg/text/template/exec.go#L93 (I use the pattern myself in certain situations. It's extremely useful.)

redbad 13y ago
Note I said "as a matter of course". I agree it's useful in certain very limited circumstances, like parsing. But certainly not database work, unless you have a very different idea of what that entails than I do. Link to code?
- burntsushi 13y ago
  It's the same principle as parsing. Database work involves lots of querying, scanning, etc. All of these operations produce errors. In the work that I do, the response to an error is usually, "rollback, show error to user." This makes it ideal for panic/recover. (And this can work well for either command line applications or web applications.)
  - vertex-four 13y ago
    Panicking isn't done when a database operation fails. Returning an error value is. It's just like old-school C. Panics are for programming errors or things like out of memory conditions, not errors in ordinary operation, even when components are failing.
    - burntsushi 13y ago
      I hate to be rude, but I feel like you jumped into this thread without reading the context. I'm not talking about panicing instead of returning errors. I'm talking about using an idiom---which is used in the Go standard library (see my link up-thread)---to make error handling more terse when you're working with code that is otherwise profligate with checking errors. At no point is a panic exposed to the user of a program or to the client of a library. At no point are errors ignored. The panics are kept within package and converted to error values.
      - redbad 13y ago
        Guarding your library boundary with a recover doesn't absolve your library internals from being nonidiomatic by using panics. (That the stdlib uses panic/recover in a few specific places does not make it broadly idiomatic.) Without seeing specific code I can't say for sure, but it's very unlikely that any database interaction code is best modeled with panic/recover for error handling. I'm very curious to see the source, at this point.
        burntsushi 13y ago
        > Guarding your library boundary with a recover doesn't absolve your library internals from being nonidiomatic by using panics. Using panic/recover doesn't automatically make your code nonidiomatic. > (That the stdlib uses panic/recover in a few specific places does not make it broadly idiomatic.) That the stdlib uses panic/recover in several places is a good indicator that "never use panic/recover" is bad advice. Note that while I agree that just because something is in the stdlib doesn't mean it's idiomatic, I also cite that this particular approach is used to make the structure and organization of code more clear. Since it's used in several packages, I claim that this is a strong hint that panic/recover is appropriate in limited scenarios. > Without seeing specific code I can't say for sure, but it's very unlikely that any database interaction code is best modeled with panic/recover for error handling. I'm very curious to see the source, at this point. It's really not that hard to imagine. For example: http://play.golang.org/p/fhpRLd8EHY http://play.golang.org/p/fhpRLd8EHY We seem to have some wires crossed. Let's be clear, shall we? * The panic/recover idiom is rarely used, but it is an idiom. * There are trade-offs involved with using panic/recover. In my sample linked in this comment, many of the functions in database/sql need to be stubbed out so that they panic. However, the cost of this is relatively small, since it can mostly be isolated in a package. * The idiom is most frequently seen in parsing because there are a lot of error cases to handle and the response to each error is typically the same. * While parsing is the common scenario, I claim it is not the only one. I cite that database work is profligate with error checking, and depending on your application, there's a reasonable chance that the response to each error is going to be the same. When doing a lot of it, it can pay off to use the panic/recover idiom with similar benefits as for doing it with parsing. * There may well be other scenarios where such handling is appropriate, but I have not come across them. I've done an unusual amount of work with parsers and have done some database work, so I've had the opportunity to bump up against the panic/recover idiom a bit more than normal. As with anything else, it can be abused. But I find it extraordinarily useful in certain situations.
  - waps 13y ago
    This is just another example of Go's fundamental attitude. Stuff is available for the language designers, but not for you : * generic functions (e.g. append) * generic data types (e.g. slices) * exceptions (like illustrated above) * special case syntax * Custom event loops * precompiler macros (very bad to use, horrible, blah blah ... except of course for the people imposing this restriction, and YES they're using it amongst other things to workaround the lack of generics in C) ... This attitude was common in middle-90s "generic" programming languages like Ocaml, Modula-2 and others. You should simply look at Go as one of those languages and treat it as such. If this attitude bothers you, you should look at C++0x and D.
    - burntsushi 13y ago
      I've read your comment twice and I cannot see any pertinent connection between it and what I said.

justinsb 13y ago

Agreed, you should be using defer, not recover. The canonical examples are closing a file and releasing a mutex. Both have code samples here: http://blog.golang.org/defer-panic-and-recover http://blog.golang.org/defer-panic-and-recover I'm confused as to what you guys are saying: are you saying that you don't need to handle exceptions (whether using defer or recover), or that it's better to use defer over recover? I take exception to the former, totally agree with the latter.

redbad 13y ago
defer and recover have nothing to do with each other, except that in the few circumstances where it's appropriate to use recover, you often do it within a defer block. > are you saying that you don't need to handle exceptions > (whether using defer or recover) Go doesn't have exceptions. You don't need to handle (i.e. explicitly deal with) panics via recover. If you do, especially if you're not making the panics yourself in e.g. a parsing package, that's a bad code smell and you're probably doing something wrong.
enneff 13y ago
defer doesn't "handle" panics. It won't stop your program from crashing. You have serious gaps in your knowledge on this subject.
- justinsb 13y ago
  My understanding is that defer is the broad equivalent of a Java finally block, and recover is the broad equivalent of a Java catch block. I think of both as ways of handling exceptions, although I see how the word "handle" could be interpreted in a way that makes my statements nonsensical. By handling I meant "doing the right thing", not "swallowing the panic/exception"; I apologize for the ambiguity you found. If you do still think I have gaps in my knowledge, I humbly suggest that you briefly fill in those gaps with facts; it should save you time in the long run and will likely win you a few converts!
  - enneff 13y ago