Omg I am a self educated begginer developer, and 3 days ago, I did the same thing. I just felt the need to throw custom error. Im glad I fid the right thing
Not long ago I had to revamp the error handling system of over 20 projects with over 5 different approachs mixed within them. Working on an enterprise level for a multibillion dollar company that has this kind of anti-pattern and literally no code review can be a nightmare, but it is extremely educational. Took me not much more than a couple of weeks of work time, but I am glad to see that the final result is pretty much what you taught on this video. Most junior and mid-level developers dont pay a lot of attention to error handling. This video is absolute gold in terms of best practices.
Thanks for sharing your story, that's very insightful. Would you say the points mentioned in the video are sufficient when it comes to the code. Or were there any other patterns you used when refactoring? :)
@@SoftwareDeveloperDiaries I really liked your approach, showing the do's and dont's (many of which I've seen during the process lol) I developed a library to centralize all error handling through a middleware, using a similar approach with an error dictionary and custom error types (easy to reuse on all projects). The biggest issue was how the errors were thrown: Promise.rejects, .catch(), just arbritrary throws and/or try-catches, or simply nothing at all... for that I went with hexagonal pattern, piping all errors towards the error-handler and its dictionary through a few adapters (simple and cleaner code) For the final result, any custom error can be simply added to the dictionary, along with a function that will handle the specifics for that error, or if the developer adds nothing custom, a default dictionary is used to create an error with all necessary logging and debbugging info.
This are some next level through experience gained codes which you are passing to new developers........with great power comes great responsibility Hats off to you I just got placed in a company after a system design interview for Fullstack Developer role just by following this playlist. Couldn't thank you more sir.
Great video. Subscribed!, I have been also following same approach. Would like to request you to consider making videos for topic like best practice, code quality, optimization, debugging, performant code etc.
Why do you need the isOperational flag? In isTrustedError if the error is istanceof AppError than is a trusted error. Is there a specific case where we need this isOperational with false / true?
you think it's okey to hardcode in the client side the httpCode ? or was this just an example and that httpCode property should only be used for network request errors?
Omg I am a self educated begginer developer, and 3 days ago, I did the same thing. I just felt the need to throw custom error. Im glad I fid the right thing
Let's goooo 🔥
Not long ago I had to revamp the error handling system of over 20 projects with over 5 different approachs mixed within them.
Working on an enterprise level for a multibillion dollar company that has this kind of anti-pattern and literally no code review can be a nightmare, but it is extremely educational.
Took me not much more than a couple of weeks of work time, but I am glad to see that the final result is pretty much what you taught on this video.
Most junior and mid-level developers dont pay a lot of attention to error handling. This video is absolute gold in terms of best practices.
Thanks for sharing your story, that's very insightful. Would you say the points mentioned in the video are sufficient when it comes to the code. Or were there any other patterns you used when refactoring? :)
@@SoftwareDeveloperDiaries I really liked your approach, showing the do's and dont's (many of which I've seen during the process lol)
I developed a library to centralize all error handling through a middleware, using a similar approach with an error dictionary and custom error types (easy to reuse on all projects).
The biggest issue was how the errors were thrown: Promise.rejects, .catch(), just arbritrary throws and/or try-catches, or simply nothing at all... for that I went with hexagonal pattern, piping all errors towards the error-handler and its dictionary through a few adapters (simple and cleaner code)
For the final result, any custom error can be simply added to the dictionary, along with a function that will handle the specifics for that error, or if the developer adds nothing custom, a default dictionary is used to create an error with all necessary logging and debbugging info.
Would be cool to see an example of this library.@@LarutanAK
This are some next level through experience gained codes which you are passing to new developers........with great power comes great responsibility
Hats off to you I just got placed in a company after a system design interview for Fullstack Developer role just by following this playlist.
Couldn't thank you more sir.
Damn, a good explanation no one is touching this depth of concepts like memory, handling error, and all stuff you are doing a great job!!
Please do a video about performance tests in node! Testing locally + setting up tests for CI/CD
You are delivering crucial things
Thank you
This is gold, thanks for sharing, expecting more like this! 🙂
that is really helpfull keep up this content
Really helpful for me. Thanks, guy.
This is good stuff...thx for posting
OMG it is so helpful, I am feeling like a Pro now😅
Happy to help 🫡
Great video. Subscribed!, I have been also following same approach. Would like to request you to consider making videos for topic like best practice, code quality, optimization, debugging, performant code etc.
Thank you! Those are already on the list ;)
Thanks for this.
Do we have to create our own error dictionary or is there some sort of npm package for it?
Why do you need the isOperational flag? In isTrustedError if the error is istanceof AppError than is a trusted error. Is there a specific case where we need this isOperational with false / true?
I am unable to understand the importance of Object.setPrototypeOf(this, new.target.prototype). Can you please explain the significance of this line.
Great video. Subscribed!
Happy to have you here, Dawid!
you think it's okey to hardcode in the client side the httpCode ? or was this just an example and that httpCode property should only be used for network request errors?
The latter! I hardcoded it just to demonstrate it as an example 😉
@@SoftwareDeveloperDiaries haha oki dokis
It's pronounced walla"bee".
Oh thanks for the hint 😅