Go Has Exceptions??

Panic is what happens whenever someone looks at my code

From the book Learning Go by Jon Bodner: "Using recover is recommended in one situation. If you are creating a library for third parties, do not let panics escape the boundaries of your public API. If a panic is possible, a public function should use recover to convert the panic into an error, return it, and let the calling code decide what to do with them."

So this isn't completely accurate. Whenever prime would talk about panics in go, he would talk about it as an intended crash behavior. And he's right about all that there probably shouldn't be a way to recover from intended crashes. However, panics can also happen unintentionally for example when trying to dereference a nil pointer, accessing a non existing index in an array, or division by 0. That's something that typically shouldn't happen and it's a core error in the code. That being said, it's probably a good thing that echo (or any other, or even custom) web server has a way to recover from that and not crash the entire server because one handler has some faulty code. It probably is a good thing that you can catch that and possibly do some logging for it and return a 500 rather than crashing the whole program. Another thing worth mentioning is that if go didn't have a method to recover from panics, it could create an attack vector where hackers would try to exploit web servers by creating a panic (many ways to do this) and instead of just getting a 500, they would crash the whole server. This becomes even more likely if you are going tiger beetle and using asserts in production. Recover is also built to work very differently than try/catch. It doesn't return the error type and you can't have different behavior based on what kind of error (panic) happened. It just allows for continuation after a panic happened and then do something about it knowing that a panic happened. I am not saying that it's impossible to use it in a try/catch pattern but it certainly isn't easy to use it in that way. The best way to work with errors in go is as values, as intended. The recover functionality doesn't go against that. Btw love prime and have learned a lot from your videos!!

Common use for recover in Go is in web servers/message queue processors. Null references, index out of range panic bugs would cause the entire web server/consumer to crash. You don't want that, especially if its a panic isolated to specific a user/message. So you will typically have a recover in your global middleware somewhere to prevent the panic escalating all the way up the stack and into a crash.

Meanwhile hardcore Python developers, trying to make sense of a two-page try/else statement in a 3rd party library with 65 stars on GitHub that hasn't been updated in 6 years...

I only used recover once, it was for an encoder/decoder that used a lot of reflection. With Go reflection, the compiler won't stop you from doing something stupid, and EVERYTHING panics. Usually I wouldn't recover from implementation mistakes but in context it made sense to put a little defer recover block at the top of my function so I could return an error.

Remember, you can't crash if you wrap your entire program in an exception.

Recover is okay if the code may throw, say, index out of range, and you don't want to crash the entire thing. You catch it, log it, and proceed. Say, a user sent a crafted request that broke some code, you don't want your server to be down for all users

It's nothing like try catch, recover only exists if you can save the panic.

That's like saying the Amiga "Guru Meditation" screen and Windows 95 "Blue" screen were Exceptions because the user could continue and "recover" from the panic