0

I do not know Go. I was going through the docs to get an idea of the language and came up against the Defer Panic Recover functionality.

Panic seems to work like exceptions. However I could not find how my code would guard against these exceptions, which can be thrown by layers deep below the ones I call. Java has checked exceptions. Does Go have something similar?

How does this work?

Edit: There seem to be 2 ways to think about this

  1. Panic is very rare and it should be allowed to kill the program as described here
  2. Panic can be used in the regular flow of code - as an example of defer panic as explained here, which describes how to use it for malformed input.

My question pertains to usage of panic in situations like 2, which seems to be easily doable.

Jonathan Hall
  • 75,165
  • 16
  • 143
  • 189
computinglife
  • 4,321
  • 1
  • 21
  • 18
  • 3
    Possible duplicate of [Golang panic crash prevention](http://stackoverflow.com/questions/25356602/golang-panic-crash-prevention) – Paul Hankin Apr 28 '17 at 12:02
  • 1
    Small note - that blog article is about three separate topics: defer, panic, and recover. Defer is unrelated to panic/recover. The article is also a little misleading; panic is generally for unrecoverable errors, not for flow control, as explained here: https://golang.org/doc/effective_go.html#panic – Adrian Apr 28 '17 at 15:09

1 Answers1

0

Sure, you can use panic to control the regular flow of the program, but I think the more idiomatic way is to just return an error to the caller in such cases (like the case of malformed user input).

Panic is normally used in exceptional cases that imply some kind of a bug in the program. You can call the panic yourself if something goes wrong, but it's also called automatically in the case of nil pointer dereference, out of bounds array access and other similiar cases. Often things like this should crash the program, which it does by default, but if your program is some kind of service, you probably don't want the whole program to crash, you just want it to stop what it was doing when it encountered the crash and return to it's normal state.

Take a web server for example, if some strange request causes an out of bounds array access due to some bug. You don't want the whole server to crash, instead you want it to exit the handler function for that request, but keep listening for new requests. The way to do that is described pretty well in your example two. So you defer a recover() function in the place where you want the panic to stop. If the recover returns an error you know your program was paniccing. You can then do some logging, maybe send an email to yourself saying that something is wrong, etc., and then continue normal program flow. But if you had some validation function that noticed there's something wrong with the request, you probably wouldn't want it to panic. Instead you'd want it to return an error the the caller (request handler) which could then answer the request with 400 bad request, and then exit the handler normally.

jussius
  • 3,114
  • 15
  • 21