The Must pattern in Golang clearly explained!

[@esra_erimez]

I strongly disagree. It is my humble opinion that error handling in Go is excellent. I think that panic is not error handling and should not be used like an exception. Edit: Once again you continue to impress. This video is an excellent treatment of the topic. Everyone, please watch to the end as the entirety of this video is important.

[@FloWoelki]

I think everyone has their opinion about the Golang error handling, but I agree with you. And Golang does not even have traditional exceptions :D I've also added a "* kind of" to the "sucks" and I think that "sucks" was harsh wording, but thank you though. Btw. I've also said multiple times throughout the video that everyone should be careful when using "panic", but thanks for the comment! Appreciate the honesty!

[@gungun974]

@@FloWoelki Yes some can think panic is an exception in disguise because you can in a defer function basically recover and cancel the panic but the intent behind panic is completely different than Exception. Exception you base your whole project to be prepared at one stage to catch and mange the error like in an HTTP controller. With exception you arrived at a point of execution in your program where something really unexpected and unfixable occurred. In this case the only thing you can do is displaying errors message and stop with panic the whole program. Maybe your golang Mux will just make sure for your http route to just kill the goroutine and return 500 but the idea of you can’t continue persist.

[@KostasOreopoulos]

panic ARE exceptions when you need to skip the stack trace. Go error hanlding is so much better than traditional try--catch throw. When you query an endpoint and you get an "error", you get an error VALUE. It is not logical to raise an exception just to signal that something wrong has happened. On the other hand, you start your application and you cannot connect to your database. If your application CAN function without the database, then there is no need to raise an exception. It is just an error value. If it cannot, there is no need to travel the whole stack back to the originating call. You raise an exception (panic) and you either exit, or recover, maybe try a second and a third time. Go's error handling is actually one of its best features.

[@benitoe.4878]

I think errors as return values is one of the strong points of the language. That it tends to result in the ubiquitous `if err != nil` and that there is no ternary operator or other facility to deal with it in another way is another and long-standing discussion :-)

[@mad_t]

If you don't want to check erors don't use Go. Explicit errors are THE philosophy of Go.

[@anon_y_mousse]

This gives me a lot to ponder. Is it more important to have a consistent error handling technique, like always use `r, err := foo(); if err != nil ...` or would it not make sense in certain circumstances to change the methodology when the return value is both the error and desired object? Consider the C way of doing things where the return value is a pointer to something and if the operation failed the pointer is NULL. So merely checking the return is how you determine if you can go on. `FILE *f; f = fopen( "some_file.txt", "rb" ); if ( !f ) ...` Also, if you call panic() in Go, do deferred operations still execute or do they get skipped?

[@gustanobreza]

Greeting from Brazil 👋🇧🇷 Excellent video, your didactic is really good. Thanks for your work!

[@FloWoelki]

Hello there :) Thank you so much for watching!

[@selvamp5775]

Sometimes it seems bad when insert same error check in multiple times within same block. But i read somewhere the best practice is that caller of the function should handle the errors. Hoping some improvement in the future.

[@adel8206]

This is honestly a bad advice. wrapping your function calls with "Must" or "CheckError" isn't any cleaner. And "don't panic" is a go proverb. I agree with you that sometimes we just wanna bubble up the errors without necessarily handling them. For that I hope the Go team add some sugar ( like the Rust's "?" operator) to make it easy to do so.

[@FloWoelki]

Sure thing and thank you for the comment, but I would disagree with that. The "Must" pattern is a well-established convention in Golang for handling errors in specific scenarios. Although it's a fair point with the panic, I've mentioned that throughout the whole video. Must functions should be used judiciously, as they convert recoverable errors into panics, which can crash your program if not handled properly. There is even a `Must` function inside the Golang codebase: cs.opensource.google/go/go/+/refs/tags/go1.23.3:src/text/template/helper.go;l=24

[@benitoe.4878]

I think panic is great when the state is truly unrecoverable. By the same token I think recover is more like an option for even more rare cases.

[@georgin.georgiev6392]

@@FloWoelki The Must functions that use the one you describe are only intended to be used during initialization and when you are 99.99% sure your program won't crash, e.g. MustCompile(regex) when your regex is static and won't change. You are defending a stance you don't fully understand.

[@MattRobinsonDev]

I learnt something new thanks. I think it's a great video, as usual!. Disagreeing with things =/= bad video :)

[@FloWoelki]

Thank you, and I am glad that you've learned something! :)

[@sighup124]

I get it, go has very verbose error handling to a point where it makes code harder to read. After doing some rust one feels the pain even more. But look this is go, and the good side of it is that any junior dev can look at the code and figure out what’s going on. And has less ways to screw error handling up when following some simple guidelines. One of them is “don’t panic”. So I think this makes things complicated by hiding logic away and it will either confuse someone or it’s likely that Must() will be used where it shouldn’t. So I’d advice to just keep things the go way or use another language. Otherwise there’s really no point because you get the worst and miss the benefits mixing it all up.

[@ColantAlan]

For case 2, when you want to return an error, it is possible to use Must, CheckErr but also add a deferred statement with recover at the beginning. If this statement is coupled with a named error argument, you can modify it and return the error. Is this a bad practice?

[@dazoedave]

Please don't use log.Fatal... Especially if your writing a module to be used by others. Some things to remember. Log.Fatal terminates the program immediately. Panic will run any defers and can be recovered.

[@dawnrazor]

I usually like your content but I think this video is a bit off. panic in go is an anti pattern and really should be avoided at all costs. There is only 1 reason to use a panic and that is if the code is going to panic anyway then issue a panic with a helpful message; ie if you are about to dereference a nil pointer then it’s ok to panic with a meaningful message rather than allow a generic nil reference panic to occur which is harder to debug. I don’t think you have appreciated how bad using panics is. Use the error checking mechanism, that’s what it’s there for. Depending on panic and recover is just asking for trouble

[@FloWoelki]

I really appreciate your feedback, and I 100% agree. I've mentioned multiple times throughout the video that you always have to be careful when using panic, but maybe that wasn't enough. I just wanted to focus on the must pattern itself. Although it is obviously also used throughout the Golang codebase where the Must pattern is also used, but yeah having detailed error messages without necessarily panicking would be much better.

[@hbobenicio]

I truly think this Must function version with generics should be on the standard library. I always write it myself in almost all my projects.

[@FloWoelki]

Yeah, I kind of agree; there was also an open discussion on GitHub about that. It's kind of similar to this issue here: github.com/golang/go/issues/32437

[@MightyMoud]

Yeah yeah naaaaah, don't use Go if you don't want to handle errors as values. Must function is a very precise knife. To be used carefully. Error as values is the spirit of GO. If you don't accept it you will just be fighting the language

[@FloWoelki]

I agree, and I also enjoy using Golang. Since this topic is still being discussed in the community, I wanted to highlight it and make a video about it.

[@jimbo0o]

👉👉👉Panic() is NOT error handling. Golang handles exceptions through the Panic+Recover mechanism. PLZ Do not mix concepts.

[@grim.reaper]

Are you using zed editor 😅? Great video btw!

[@FloWoelki]

Thank you and yes :)

[@Go_with-Christ]

Love the golang kids crying that you must handle errors when using golang. This pattern is effectively an assert, and you use asserts in cases where you need to crash. For static content known at compile time, like a fucking regex, this decreases verbosity and increases the readability.

[@gearboxworks]

Except regexp already has a MustCompile(), and while I am sure due to the difficulty of proving a negative there is at least one other similar scenario where there is not a built-in "Must" I cannot actually think of any. Maybe you can think of one?

[@knofi7052]

Just be aware that wrapping your functions in other functions shouldn't be used in performance critical sections.

[@akeutel83]

Danke, du solltest den genialen Content auch in deutsch bringen, wir brauchen mehr deutsche GoLangDevs

[@gearboxworks]

Honestly I think posting this video as-is was rather irresponsible. Too often you show Must() w/panic() and imply it is a good practice because of how it "simplifies the code." Viewers who don't watch the entire video or who are not good at noticing nuance, and who don't read the comments will likely see your praise of Must()+panic() and leave thinking it a practice they should emulate. On the contrary, there are very few use-cases where panic should ever be used, and certainly not in code intended for production use. IMO you really should add a very obvious disclaimer to the beginning of the video saying you "were just showing how Must() works, but please do not ever actually use it for anything other than personal use or for testing." #fwiw

[@FloWoelki]

Thank you for the feedback! I've added a few disclaimers (descriptions and an info card). I hope that this is enough.

[@gearboxworks]

Not enough. At least change the text on the thumbnail from "You Must use this" to "Must you use this?" or similar. That thumbnail sets the tone of the video to be about a best practice rather than a cautionary tale.

[@FloWoelki]

I'll see what I can do here :)

[@gearboxworks]

@@FloWoelki - Kudos for the responsiveness to criticism.

[@user-eg6nq7qt8c]

I rather like the error checking in Go! If go just improved the syntax over if err != nil {} I honestly wouldn't have anything to complain about .

[@FloWoelki]

I think there are even some thoughts for "Go 2.0" where a more improved version of the error checking was proposed.

[@gearboxworks]

@@FloWoelki- The Go team announced they decided there would never be a "Go 2.0" as they originally discussed. They decided maintaining backward compatibility is the most important language attribute.