best practices to throw error on backend
I see people using throw new error and throw error
But for me i kinda prefer having standard patterns across all the apis
17 Replies
Errors in JavaScript world are too unpredictable and messy for
throw
to be useful to me.
so yes, I'd either return
or if I don't care about the error message itself, I usually just
I'd say the first is a best practice for a library (that's what libraries like TanStack's do), and the other one is up to you to decide for your case
1
2
await
+ then()
? 🤔 Choose your weapon lollol I only
await
the value I care about. I don't need res
itself so I won't assign it to a variableIt looks weird to mix them up imo. The whole point of
async await
is to get rid of them()
😅
Plus it's confusing about what is actually returned here, you force the reader to pay more attention about what's finaly returnedI agree it may be confusing, but especially with
fetch
and .json
, I find it more appealing than:
I wouldn't use then
in more complex cases, but for this one, I'll almost always do the same: fetch, json, & extract result.
Do you have a cleaner way that also handles all possible errors?The last one looks less confusing if I was the reviewer, I'd spend less time thinking about what's going on
For me the last example you provided is good enough, it's clear
Fair enough, and almost the same amount of code. I just have variable-phobia in JS I guess lol
Haha I understand, but at least it provides documentation without writing documentation 😁
I just use errors
And throw them
I worked on a project that used to use monads
Then we stopped and ripped them out
@Alex | C4 model stan How do you make sure all possible Errors are handled? Do you just always try-catch? If so, where do you try?
You can’t make sure all errors are handled, the program could always just crash
I subscribe to the “let it crash” philosophy for some errors, and then for known errors I try to catch where it makes sense (as close as possible to the source)
I never throw errors in utility functions.
I return Error or Type
Basically like Result in Rust
Then I check where I use it
If it's of type error, then there, I handle it.
Instead of an ugly try catch block
I would validate it with Valibot too but you get the idea
Love this, and yes, Rust's Result and Option are awesome.
still need to check its of type string
just because you cast it as it doesnt mean it is
I tweaked the one above.
Still need a
?.
Accessing undefined will make the server shit itselfThat's a "this is fine" meme right here lol. With all of that, validation is still very much needed in serious apps
I suspect Error would result in some weird behavior if used in tRPC since it's an instance of a class, not just a normal object?
but otherwise I'd say this is clean and easy to work with
"used in" as in, returned from a tRPC function and used like an Error class instance in client side
Also, I highly recommend you look into https://ts-rest.com/
🪄 | ts-rest
Incrementally adoptable type-safety for your new and existing APIs
I agree with prime that using monads in ts is just too messy
Great in rust
Not so great in ts
When I was a junior I used to use result types a lot but less so now