Advanced Go Panic Programming I do it cause I need to… Prerequisites This article expects you to be already familiar with , & functions and with any other programing language which has ( ) concept. golang panic recover exceptions try-catch Introduction You probably have already seen in “ ” something like this: The Little Go Book Go’s preferred way to deal with errors is through return values, not exceptions And maybe you’ve seen ” ” page on go wiki, which says: CodeReviewComments Don’t use panic for normal error handling. Use error and multiple return values Also, you may have already seen “ ” article which says: Effective Go The usual way to report an error to a caller is to return an error as an extra return value Also, you may already seen on Dave Cheney’s blog article “ ” which says: Why Go gets exceptions right When you panic in Go, you’re freaking out, it’s not someone elses problem, it’s game over man And it may feels like panic is something that it’s better to avoid in own project….But does it mean that no one use panic?Let’s check it out! Let’s run next command against popular projects and see whether panic is something that no one using: go grep "panic(" -r --include=*.go . | wc -l Results: +-------------+-----------------+| name        | count of panics |+-------------+-----------------+| |            4050 || |            4087 || |              46 || |             693 || |            1161 || |              14 || |             157 || |               9 || |               5 || |              46 |+-------------+-----------------+ go kubernetes gin prometheus terraform echo dep gorilla mux mysql pq Well… How to live with it At first sight, it may feels confusing that documentation, books and articles say don’t use panic but reality is another and we can see panics everywhere… Hope you will be agree with idea that panic is not something simple to say “use or don’t use”. So let’s try to dive deeper and clarify where is the boundary between bright and dark sides of panic and why we have such a big number of panics on github and why all books and documentation don’t like panic. What is panic says: Official documentation The panic built-in function stops normal execution of the current goroutine “ ” wiki page says: PanicAndRecover The panic and recover functions behave similarly to exceptions and try/catch in some other languages And “ ” also says: Go by Example A panic typically means something went unexpectedly wrong. Mostly we use it to fail fast on errors that shouldn’t occur during normal operation Okay… Now it feels that panic is something like exceptions in other languages and it explains a big count of panics in github projects mentioned earlier. But if you had seen Dave Cheney’s blog article “ ” you may have seen this: Why Go gets exceptions right you might imagine that panic is the same as throw, but you’d be wrong And it means that panic is little bit different from in other languages and has own advantages and disadvantages. throw exception Advantages Like in other languages stops program execution and unwind the stack to the top-level function call. throw exception No need to deal with multiple return values, no need to write boring check: .As result — code is easier to read. if err != nil { // handle error } Disadvantages Will stop the program in case you don’t . recover When performs unwind the stack it collects information about whole call stack and it may be slow. go Function returns and you have to perform type check for obtained value which may be slow (especially in case of reflection). And it’s not like certain in other languages. recover interface{} catch exception Function won’t stop panic in case of panic in . And it’s also not traditional way of like in other languages. recover goroutine try-catch When to use panic Now it’s clear that panic is sharp* tool, and you have to think twice before using it. And it explains all cautions provided in the introduction section. Also “ ” says: Effective Go One possible counterexample is during initialization: if the library truly cannot set itself up, it might be reasonable to panic And if you have case when it’s impossible to continue execution due to some circumstances you may stop the program with panic. One more extra reason to use panic I believe in case you’re building reach application with sophisticated business logic and layered architecture (moreover, with support domain-driven design) — you have to use panic.You may hate me, but I believe it is the only way don’t drown in errors handling and have clear business logic. Panic everywhere First of all, numbers provided in introduction section means that we always have to handle panic (even though we don’t use panic in our code explicitly)because something downstream may panic even language itself may panic, and with purpose avoid program stop we have to have panic handler ( ).It’s also very important in case project has user interface (gets commands/requests from users/other services and provides results/responses) because we always must provide result/response in determined message format even in case of unhandled critical error.So in we have to have something like this: recover main.go func main() {defer func() {if r := recover(); r != nil {// handle panic}}()// ...} It’s just simple example, but you may read more about . defer-recover here Also it’s important admit that you have to have in case you’re starting new otherwise you won’t handle panic from .You may read more about this in book “ ” in chapter “Handling errors and panics”, and here I’ll provide most interesting pictures: defer-recover goroutine goroutine Go in Practice Normal flow. Panic. Syntax sugar Once you start to use panic more often you also have to perform more often and with purpose to do it in little bit pleasant way you may use something like package . The main idea under the hood of this package — is just simplify panic recovery and provide an opportunity to perform recovery in next way: recover recover You may find this syntax very similar to the traditional way of from other languages but the main goal of this approach is simplicity and conciseness, also, it’s easy to read, understand and predict behavior of this code block. catch exception Comparison Let’s compare two approaches: 1 — return error, and 2 — panic.For comparison let’s use simple example: suppose we have: — service which creates a user on facebook, twitter and pinterest. facade which calls facade service, checks errors and prints result.Sequence diagram looks like this: controller Implementation #1 Here you can see super simple function in controller, which calls then checks error from service and prints result (everything clear, simple and straightforward). SignUp service.SignUp This code is known to be idiomatic to handle errors in . And it’s great! go But when it comes to service — here you can find lot of repetitive code and it feels like something is going wrong… (You can find source code ). here Implementation #2 Here you can see the same function in controller, which calls then performs (by package) and prints result (same flow).And if you take a look to service you may find that now it looks way shorter and simpler and it’s easier to read and understand such business logic. SignUp service.MustSignUp recover recover But this code is known to be prohibited in due to reasons specified earlier… go (You can find source code ). here Is it really bad Technically both implementations equal and provide same functionality, same errors and same results (you can check it out ).But regarding amount of code — it’s obvious that 2nd one is simpler, you can see it on next picture: here Also, 1st implementation doesn’t have but it should because every user-friendly project has to have recover and it means that 1st implementation will have even more code. recover Is it slow Perform benchmarking on such small examples may looks silly but anyway let’s see how it looks and figure out whether we have skewed numbers: +---------------------------------+----------+----------+| case                            | imp. #1  | imp. #2  |+---------------------------------+----------+----------+| error: username cannot be blank | 53000 ns | 45000 ns || error: username already taken   | 51000 ns | 46000 ns || ok                              | 32000 ns | 34000 ns |+---------------------------------+----------+----------+ Looks like in case of error — panic faster but in success case — takes some overhead…Please pay attention, all provided numbers represent time in nanoseconds,and it means: for this particular case we don’t have a big difference between both approaches… recover (You can find source code related to this benchmarking ). here Go 2 draft You probably already know that in error handling will be improved with combination (if not — please ) and it will simplify everything in really elegant way!But will it help to build sophisticated layered applications?And the answer is yes for pretty simple applications like in our case (controller-service) but unfortunately for big applications and especially for applications with support domain-driven design won't help,and I believe you will still have to use panic… go 2 check-handle take a look check-handle Conclusion The point of this article is to show that panic it’s just a tool and you don’t have to afraid this tool, you have to know when and how to use panic…And once you know advantages and disadvantages of this tool you may leverage whether use it or not. PS You can find demo project with layered architecture (not DDD but many layers) which is build with the idea of panic everywhere, maybe it will be illustrative. here Also, you can find more examples of using both approaches . errors vs panic here In case you don’t like panic you may find how to simplify error handling in another way. another approach

Flow

Amazon

Facebook

Super

Twitter

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

Panic like a PRO

Too Long; Didn't Read

Companies Mentioned

Coin Mentioned

V. K.

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Panic like a PRO

Too Long; Didn't Read

Companies Mentioned

Coin Mentioned

V. K.

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES