Use ‘unknown’ instead of ‘any’ in TypeScript (Try / Catch error handling)

[@ByteGrad]

👉 NEW React & Next.js Course: bytegrad.com/courses/professional-react-nextjs

[@ismoiljonabduqahhorov5825]

Hello ByteGrad I was struggling with error handling and your tutorial really helped dealing with errors loved your content good luck

[@elenamikhaylova5086]

Thank you for explaining this well, i have banged my head on JS error handling for so long

[@renjithpn2002]

This is art, loved it 🙂

[@npaul1440]

Your tutorials and content are A Class. Just get a better microphone if possible. Thanks

[@mujibulhaquetanim]

yap, sounds is too low.

[@vincenzocristiano135]

This is pure gold! Thanks a lot!!!

[@honkhonkv2236]

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()" ?

[@MailarYT]

Your really good explaining, keep going Cheers

[@СергійК-ш4у]

thank you for sharing this topic

[@loydcose2780]

This is awesome!

[@solosdev6946]

Thanks finding a solution for this :D

[@grugbrain]

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.

[@SyTruong-d3d]

We still not consider the case where "message" is also an object

[@meka4996]

Amazing! Thanks

[@bheemkumarthami]

Thanks a lot. keep going

[@Bravin_Joshua]

Nice lesson on error handling though

[@andrevinsky]

Wrapping an unknown in a String() call does not actually constitute casting, strictly speaking, as it’s either this or this: as string. Wrapping stuff in a String() call actually replaces the value of the unknown with a string equivalent. Not casting
That note aside, I really like videos. Appreciate the effort

[@antonapalanyuk338]

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

[@namstel9225]

I prefer
typeof error?.message === "string"

[@scide-x7242]

Thank you chris

[@Axorax]

I didn't know there was an unknown type 😮

[@AFE-GmdG]

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.

[@ByteGrad]

Good point

[@mryo_]

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";
};

[@ajaychandel9976]

cool

[@charuwaka1]

use a generic API response wrapper

[@virtual5754]

const res = ... as unknown as any

[@deatho0ne587]

What if error.message is is an object, HTML, etc... Casting to string then would not be really safe.

[@ByteGrad]

Good point

[@deatho0ne587]

It is good for another video about TypeGaurds maybe.

[@ciach0_]

Then that would be [object Object]

[@deatho0ne587]

The thing is even if it is an object should you trust it for display purposes?

[@lucio9601]

God, I hate TS. Yet its so needed.

[@AriadyPutra]

message = `${error}`

[@supremecommanderz]

just type and be happy:
error?.message??'errors happens'

[@charuwaka1]

use zod

[@silenthooman]

the fn is async, and he used the then, man just use await