Error Handling in Express

Sdílet
Vložit
  • čas přidán 9. 07. 2024
  • 🔥More exclusive content: productioncoder.com/you-decid...
    Twitter: / _jgoebel
    Blog: productioncoder.com
    Code: github.com/productioncoder/ex...
    In this video, we cover how do error handling in express and Node.js. We explain how to return expected errors and how to not leak internal details of your application in case of unexpected errors.
    00:00 application walk through
    01:30 a better way of hard coding HTTP status codes
    02:36 defining API errors with status codes
    04:19 creating an API error handling middleware
    07:14 making use of next in express
    08:14 plugging our our api error handling middleware into our router
    08:55 making use of our predefined API errors
    10:17 testing our error handling
    11:03 preventing leaks from unexpected errors

Komentáře • 84

  • @stiventson4464
    @stiventson4464 Před 3 lety +18

    The way you implemented it feels like the way it was intended to be, I found this really helpful

    • @jgoebel
      @jgoebel  Před 3 lety

      Thanks, I'm glad you liked it 👍

  • @PadurariuDragosh
    @PadurariuDragosh Před 3 lety +2

    Great explanation ! Sort, easy and with big impact!

  • @Felipe-53
    @Felipe-53 Před 3 lety

    Probably the best vid on express error handling, thanks!

    • @jgoebel
      @jgoebel  Před 3 lety

      thx, I'm glad it helped!

  • @pratikbhangale2982
    @pratikbhangale2982 Před 3 lety

    I was looking for this approach from a long time. Thanks a lot

    • @jgoebel
      @jgoebel  Před 3 lety

      you're welcome Pratik 👍

  • @joeygarcia7826
    @joeygarcia7826 Před 2 lety

    Loved the video! I would like to see one like this doing Content Negotiation and using the route information to know whether or not to throw a 406 or 415 if you have a variety of routes (GET & POST) and you have to know based on the route whether this route would ever be returning a payload, if not, then no need to throw a 406 error. Similarly for the 415.

  • @pPablo240
    @pPablo240 Před 2 lety

    Perfect, simple and efficient. Thanks man

  • @izichtl
    @izichtl Před 2 lety +1

    This video blow my mind to a new perspective, thank you

  • @JitendraDalai
    @JitendraDalai Před 3 lety

    As clean as it could be. Thanks for sharing.

  • @pryansh_
    @pryansh_ Před rokem +1

    i luv u 💖💖 , u might not know how much you helped me.

  • @nicogarcia7302
    @nicogarcia7302 Před 2 lety

    Awesome explanation, it was really helpful👏🏽 subscribed!!

    • @jgoebel
      @jgoebel  Před 2 lety +1

      Awesome, thanks Nico 👍

  • @EricOnYouTube
    @EricOnYouTube Před rokem

    Well done! Thanks for this.

    • @jgoebel
      @jgoebel  Před rokem +1

      Glad you enjoyed it!

  • @rachidb9624
    @rachidb9624 Před rokem

    Thank you very much mate, helped me a lot !

  • @anuragkuradia2676
    @anuragkuradia2676 Před 2 lety

    thank you, I was looking for this solution for days.!!!!

  • @shadigaafar3091
    @shadigaafar3091 Před 2 lety

    Thank you so much, that was very helpful!

  • @kamil3409
    @kamil3409 Před 3 lety

    Really clean explanation, I'm going to use this in University Project. Have a good day.

    • @jgoebel
      @jgoebel  Před 3 lety

      thanks, I hope it helps 👍

  • @anuteimatei7119
    @anuteimatei7119 Před 2 lety

    Good tutorial. Keep up the good work!

  • @tech3425
    @tech3425 Před rokem

    Got a lot of insight from this video

  • @peternicola6429
    @peternicola6429 Před 2 lety

    what a great channel man 👍💪, I saw some of your videos and you are a really good teacher man, so happy I stumbled upon your channel .. one question I have is what do you mean by data leakage .. what kind of data do you mean, like where the code errored out maybe or what?

    • @jgoebel
      @jgoebel  Před 2 lety +1

      e.g. let's assume you have some manhandled error, you might by accident return the call stack to the client. This might be problematic in terms of security.

  • @matteocinti6482
    @matteocinti6482 Před 2 lety

    Would you consider throwing an error instead of returning it in the class constructor?

  • @missiontechdk6064
    @missiontechdk6064 Před 2 lety

    Outstanding explanation sir 🏆

  • @OleksandrDanylchenko2k

    Thank you a lot!!!

  • @santiagoguerra8826
    @santiagoguerra8826 Před 3 lety

    Thank youuuu!!

  • @foreveryoung6108
    @foreveryoung6108 Před 2 lety

    Thanks for useful info

  • @Euquila
    @Euquila Před 3 lety +4

    In case someone is wondering, how does express know it's an error handler middleware ? The number of arguments is 4!!! (err, req, res, next)

    • @jgoebel
      @jgoebel  Před 3 lety +1

      exactly Euquila. Thx for the nice addition 👍

  • @jusamuel4246
    @jusamuel4246 Před 3 lety

    Great way to use class for error handling.

  • @gatoloco1873
    @gatoloco1873 Před 2 lety

    What is the purpose of "static internal" method if you nerver used it?

  • @deretano_fondelli
    @deretano_fondelli Před 4 lety +2

    I personally would leverage try catch block and extend ApiError to the native Error object

  • @codinginflow
    @codinginflow Před rokem

    I like your stuff. I saw that you're German as well so Hallo von mir 👋

    • @jgoebel
      @jgoebel  Před rokem +1

      Thx, schöne Grüße nach Erfurt 😁

  • @lukelu
    @lukelu Před 2 lety

    Great tutorial, very logical. Just wondering how to send error message to the front end, do we need another res.send to send error message ?

    • @jgoebel
      @jgoebel  Před 2 lety

      Hi Luke, we return the error message in the error handling middleware that we plug in at the very end

  • @tinpham6413
    @tinpham6413 Před 2 lety

    5:38 Thanks for point it out, I alway wonder why I can't console in nodejs

  • @pPablo240
    @pPablo240 Před 2 lety

    The generic error gona work for every kind of error? Like bugs, connection problems with db, etc ?

    • @jgoebel
      @jgoebel  Před 2 lety

      yes, any error that is not anticipated, i.e. that is not an instance of ApiError will be caught

  • @abdurrakibrony_518
    @abdurrakibrony_518 Před 3 lety

    nice

  • @kruuuux
    @kruuuux Před 3 lety

    thanks

    • @jgoebel
      @jgoebel  Před 3 lety +1

      thx Konrad, you're welcome!

  • @privacypolicy9201
    @privacypolicy9201 Před 2 lety

    why you return; empty just to stop the program instead of returning next(new ApiError(404,blabla)), is there any difference?

    • @jgoebel
      @jgoebel  Před 2 lety +1

      because then it would look like you have to return the value of the next(new ApiError(...)) which you don't because the call to next just passes on the control to the next available middleware.

    • @privacypolicy9201
      @privacypolicy9201 Před 2 lety

      @@jgoebel so the middleware will stop passing to next() till that point?

  • @turan_sultan
    @turan_sultan Před 3 lety

    Is it acceptable to use ApiError inside services? Or is it intended to be used only in controllers?

    • @jgoebel
      @jgoebel  Před 3 lety

      I would primarily use it in controllers because the service layer should only handle business logic

    • @turan_sultan
      @turan_sultan Před 3 lety

      @@jgoebel I'm a bit struggling with handling business logic errors. Imagine there is a login service, which can throw errors because 1) Username can't be found, 2) Password is incorrect. The appropriate status codes would be 404 and 400, respectively. However, since the business logic shouldn't be aware of http stuff, how the controller knows which status to send to the client?

    • @jgoebel
      @jgoebel  Před 3 lety +2

      @@turan_sultan you could throw custom errors and then depending on what error you get, you return the proper status code. The error handling shown in this video is the simplest form of error handling available.
      Technically speaking you could make it more sophisticated, make custom errors and then check in your error handling middleware which error it is. Now if somewhere in your service an error is thrown, you would eventually end up in the error handling middleware which would automatically return the correct status code. In this case the controller would not be involved. This approach is probably the most flexible one

    • @turan_sultan
      @turan_sultan Před 3 lety +2

      @@jgoebel Thank you, the second method is what I will probably implement. I don't know if it is just me, but it is rare to find a proper way of doing a thing in express, especially when it comes to architecture. Many times I find myself reading articles/stackoverflow on Nest.js or Java Spring.

  •  Před rokem

    It's clear and simple but, when you work with async functions it all gets messy

  • @user-ez6xb3rf3p
    @user-ez6xb3rf3p Před 3 lety

    subscribed

  • @sumitpandey6958
    @sumitpandey6958 Před 3 lety

    bro i have .unshift error in my code plse help me out of it in express

    • @jgoebel
      @jgoebel  Před 3 lety

      Hi Sumit, I don't think this is related to the error handling code in the video because there we do not use unshift

    • @sumitpandey6958
      @sumitpandey6958 Před 3 lety

      Sorry but i was doing a blog website project by git hub of clever programmer so i got an error ao i thought here i have chance to get help😅 so that's the reason i wrote my issue.

    • @sumitpandey6958
      @sumitpandey6958 Před 3 lety

      Plse help me on that problem

    • @jgoebel
      @jgoebel  Před 3 lety

      @@sumitpandey6958 Looks like your array at which you call unshift is null or the indexes which you are passing are already out of bounds

  • @mohityadav21
    @mohityadav21 Před 2 lety

    In api-error--handler.js, you are checking if err is instance of ApiError. What if we have a large number of Error classes, do we check if error is instance of a specific error class? And why do we check this? I don't see any point of this, we are just setting the status code and sending the error message as json. Shouldn't this be common for all types of errors? Or we can just inherit all errors from a common class and check only if error is instance of that base class?

    • @jgoebel
      @jgoebel  Před 2 lety +3

      we do this to not by accident expose any internals to the client (in case there is an error we do not anticipate). Yes, you could also create your custom error types and inherit from Error directly

    • @mohityadav21
      @mohityadav21 Před 2 lety

      @@jgoebel got it. Thanks

  • @Pareshbpatel
    @Pareshbpatel Před 10 měsíci

    {2023-09-01}

  • @huh_wtf
    @huh_wtf Před 3 lety

    zoom a bit more next time😅

    • @jgoebel
      @jgoebel  Před 3 lety

      sure, will do next time

  • @christianaustria741
    @christianaustria741 Před 4 lety

    the github repo doesn't exist

    • @jgoebel
      @jgoebel  Před 4 lety

      thanks for the hint. Sry. I forgot to make it public. Now it should work: github.com/productioncoder/express-error-handling