► 33% OFF on my Go + HTMX + Templ Course PRESALE bit.ly/3UFruxO ► Full Projects, Mini courses, Resume reviews, and Coaching thetotalcoder.com ► Join my Discord community for free education discord.com/invite/Ac7CWREe58 ► 60% OFF on my Golang course fulltimegodev.com Goose GitHub: github.com/pressly/goose Thanks for watching

This approach is absolutely appropriate because it implements the paradigm of error handling at the source 👍

The next vid should be: A Beautiful Way To Deal With LOGGING in Golang

@anthonygg_

Ай бұрын

Thanks good idea.

@mecamon

Ай бұрын

I approve this

As a typescript / nextjs dev transitioning to Go, this is GOld. Cheers!

This is beautiful. The only thing i'd say you're missing is generating a request id per request so that if a bug report is filed either by a consumer or a user of the frontend, they can included that request id in their report and you can look up the log messages for their specific request(s).

@anthonygg_

Ай бұрын

Yes will do that as wel. Thanks

This is such an elegant organization. I'm sorry, I'm stealing this :) Your Make() function translates beautifully to Echo's HTTPErrorHandler callback. Very, very useful video. Thank you so much for this Anthony

@anthonygg_

Ай бұрын

Thank you

You're the daddy of golang. Keep it GOing!! 💪💪💪💪💪

I love your content and this new layout of videos where you just pick one topic and just keep the video short and concise is really good 🎉❤

Even thought I'm not completely convinced with returning errors as a default, i see how this can be very clean, more so if you implement this useful error types.

This is pretty clean

The beauty of errors in golang is its open to different implementations. I always try to improve my handling and get new ideas. For now my take is the following. There are three type of errors I want to handle 1. User validation errors, or sql errors that are results of a query 2. Server errors that are expected (for example server is down) 3. Server errors that should not happen. For example Json marshal/unmarshal Which means my validation is wrong somewhere. The last 2 are internal server errors, which I want to bubble and wrap as they get to the handler, since it will create the path trace. I also might want to trigger some action (for example special log or email to the admin to handle it asap). The first one should have a fixed response for each error and will not wrap. So the error message from the origin of the error bubbles up intact. Of course there is a another issue to solve when the api is multilingual.

Nice vid! I was working on this earlier today. Side note - some people have 2 letter names

@zyriab5797

7 күн бұрын

There's a nice article out there about names. Some people don't even have last names, etc

The Make() function is absolutely useful, but I wish you would name it differently.

@anthonygg_

Ай бұрын

MakeHandler

Is there any reason why you're not using `errors.As()` to check if your error is an ApiError?

@anthonygg_

Ай бұрын

Good question. Didnt thought about that

@matiasbpg

Ай бұрын

Agree, that even for this example is the same thing, error.As is more robust and will work if you error wrap down the function stack

This is the reason why I use Fiber instead of standard library or Gin.

@mohamedmacow3610

Ай бұрын

U can do the same in Gin tho

@BryanT369

Ай бұрын

@@mohamedmacow3610exactly. I do the same in Gin all the time.

@iCrimzon

Ай бұрын

Theres no difference between frameworks, all they do is remove boiler plate from using standard library, but liking Fiber over Gin if youre used to it is fine too

@umardev500

Ай бұрын

​@@mohamedmacow3610 fiber more good docs and ui in docs and in core it's convenient than the other

@bobsimple8291

Ай бұрын

@@iCrimzon not true about fasthttp-based frameworks

Great episode as usual, Just I have one concern what if you make the invalidJSON veridic func then u can throw away the InvalidJSONData and ur code will be very idiomatic

Great video, thanks for share! I have one concern about return a message string sometimes and others an object, seems a little confuse. Could you comment about, please?

which theme in vs code do you use? i am searching this theme veeeery long

Is there a reason why you do not use the http.Error() function of net/http package? I use it like 'if err != nil {http.Error(w, responseErr.Message, responseErr.Status) return}'

Can you make an updated API series where you build a complete JSON api with the std library router with postgres and error handeling like this? That would be awesome

Hello! I've read in the docs of body for HTTP request that it's closed automatically by a server, so it's not necessary to call defer r.Body.Close() in any HTTP handler.

What VSCode ext for Rest Api calls are you using?

@leepowelldev

Ай бұрын

Looks like Thunder Client

GOat

What is this "TC" file or something for sending requests? I see it for the first time, I am always using Postman to do these, but sometimes running one request for quick test inside VSC could be handy and I don't want to run "curl" :P

@zacharybrown9842

Ай бұрын

He's running a plugin called Thunder Client, i.e. TC and you can save all your api calls in tc files. Similliar to postman but integrates nicely into the IDE

@konradpiotrowski9549

Ай бұрын

@@zacharybrown9842 Awesome, thank you man!:)

What happens if i dont close r.Body?

your ob'ekt instead of object sounds like ... a music to my russian ears ))

How can I access this code?

Just curious how the request validation is done. Is it a custom implementation?

@anthonygg_

Ай бұрын

Yeah its custom. You return a map with all the errors. name: ….., email: ……

@arsenidziamidchyk2972

Ай бұрын

@@anthonygg_ Yeah that's clear. But how do you do the validation itself? I guess you're using some schema/validation package for that

@anthonygg_

Ай бұрын

@@arsenidziamidchyk2972 if len(email) …. Just custome logic

@arsenidziamidchyk2972

Ай бұрын

@@anthonygg_ Oh got it, thank you!

I do wonder why `defer r.Body.Close()` is after error check for JSON)) Won't it cause troubles?

@anthonygg_

Ай бұрын

Why its defer 😂

@fulopzoltan349

Ай бұрын

defer means it will run AT THE END of the function call.

@jonathanalonso6492

Ай бұрын

Adding the `defer` tells the compiler to run `r.Body.Close()` at the end of the function. It's a neat way to group code that is an "allocate" and "free" for the same resource, instead of having to remember to manually add the "free" (or "Close()" in this case) at the end of the function.

@yaroslavmamykin981

Ай бұрын

@@anthonygg_ but if there is an invalid JSON in body then request body stream is not closed?

@user-yu4xm9ou4e

Ай бұрын

​​​@@yaroslavmamykin981 this is actually like `finally` in try-catch clause in C-like languages. So it will execute anyway

strange, I am doing this without having the handler throw an error. I guess its all about preference.

Just commenting to comment. This feels really convenient but not very go like. This ads a lot of inderection and unnecessary layers when the same functions could just write directly to the response writer. Which would be much simpler and clearer and do away with two or three unnecessary layers of inderection. But this is pretty much the same discussion for the 10th time on if handlers should returns errors our write to the response.

So what I currently do with the net/http library is use panic in controllers and recover it in a central error handling middleware. I can pass my custom error interface which the middleware can use to send data. Any problems with this approach?

@mohamedmacow3610

Ай бұрын

Yes ur using panics

@rampandey191

Ай бұрын

@@mohamedmacow3610 could you elaborate why that is a problem?

@fernandoacorreia

19 күн бұрын

I believe he means that panic is not meant to be used for flow control.

is there real people that make money from Golang outside of back end jobs

@yung5943

Ай бұрын

I’m interested in this too . Would love a vid on making money with these skills besides traditional employment

Again we discover the wheel aye :P? Just use a framework do your job and that's all. Time is money you are not special, make it worthy.

@zyriab5797

7 күн бұрын

The wheel is a perfect invention, there's no perfection in software. It's good to know what's going on in your code, sometimes it's worth it on the long run to not rely on stranger's code, work ethics and time. I think it's more of a balancing act: time vs control, in a way.

@matthiaslangbart9841

6 күн бұрын

Yeah. Just order some pizza for your guests. Cooking is just a waste of time, right? Well, until your pizza service fails. Are you prepared for that?

@OwNeDGr

6 күн бұрын

​@@matthiaslangbart9841 Yeah, of course, cook it yourself! You need to build your house, then you need to build your kitchen and your electricity. When you finish, maybe around 5-10 years if you are lucky, and if your guests are still alive, maybe you will have cooked a pizza. Now change the word 'guests' to 'clients' and 'pizza' to 'money'.