Hello, awesome channel for a noob like me! I was wondering, at 10:42 in our utility function couldn't we just omit to type the message as string and instead in the return do something like "return message.toString()" ?
That's exactly how I handle request errors in our projects. 😅 Those Python develelopers cannot agree with Java developers on error response, and they both think it is easy to handle those errors in the client side.
I would write ... else if (error && typeof error === "object" && "message in error && typeof error.message === "string") { ... If there is a message in an error object but it isn't a string, it should possibly use the default error message instead.
👉 NEW React & Next.js Course: bytegrad.com/courses/professional-react-nextjs
Your tutorials and content are A Class. Just get a better microphone if possible. Thanks
yap, sounds is too low.
use a generic API response wrapper
just type and be happy:
error?.message??'errors happens'
This is art, loved it 🙂
Hello, awesome channel for a noob like me! I was wondering, at 10:42 in our utility function couldn't we just omit to type the message as string and instead in the return do something like "return message.toString()" ?
Thanks.
export const getErrorMessage = (error: unknown) => {
if (error instanceof Error || (error && typeof error === "object" && "message" in error && typeof error.message === "string")) {
return error.message;
} else if (typeof error === "string") {
return error;
}
return "Something went wrong";
};
Hello ByteGrad I was struggling with error handling and your tutorial really helped dealing with errors loved your content good luck
We still not consider the case where "message" is also an object
Your really good explaining, keep going Cheers
I didn't know there was an unknown type 😮
I prefer
typeof error?.message === "string"
Thank you for explaining this well, i have banged my head on JS error handling for so long
That's exactly how I handle request errors in our projects. 😅 Those Python develelopers cannot agree with Java developers on error response, and they both think it is easy to handle those errors in the client side.
message = `${error}`
Thanks finding a solution for this :D
use zod
cool
thank you for sharing this topic
This is awesome!
This is pure gold! Thanks a lot!!!
Amazing! Thanks
What about to save mark as 'any' and use following: console.log(error?.message || error?.stack || error); It is suitable for all error data types
I would write
... else if (error && typeof error === "object" && "message in error && typeof error.message === "string") { ...
If there is a message in an error object but it isn't a string, it should possibly use the default error message instead.
Good point
Thanks a lot. keep going
const res = ... as unknown as any
Thank you chris
What if error.message is is an object, HTML, etc... Casting to string then would not be really safe.
Good point
It is good for another video about TypeGaurds maybe.
Then that would be [object Object]
The thing is even if it is an object should you trust it for display purposes?
the fn is async, and he used the then, man just use await