@airtwee
But what if you would take different actions based on the exception type?
Like handling an ApiException differently than a TypeError, for example.
I'm really curious if all devs create their own handling system which seems so off to me for something standard as exception handling.
@jorisvaesen You'd use type predicates in the catch statement to sort out what kind of exception you're looking at.
Type predicates (formerly guards) are predicate functions that take in a value of a broad type, and return the result of a boolean expression, but have a special return type that assures the caller the input value is of a specific type.
This only works in TypeScript.
https://www.typescriptlang.org/docs/handbook/2/narrowing.html#using-type-predicates
@jorisvaesen
You're not missing anything, welcome to #TypeScript lol
The type check will coerce future references of the checked value to the type the predicate checks for, which is nice for development but not much else.
@unshittifier
So a fancy if with type checking and casting basically. At least the type checking is reusable that way.
Aren't there any popular packages who tackle this problem? I'm currently using vue3 but can't seem to find anything broadly used. Guessing every dev builds their own system, which is a shame for such standard behavior.
@jorisvaesen I think this is where there's a difference in paradigm between PHP and the JavaScript ecosystem.
PHP and other OOP languages that lurk on the backend in my experience tend to prefer elegantly handling a crash whereas JavaScript and everything built on top of it avoids raising exceptions as much as possible.
Likely this is a result of how exceptions are handled i.e. well in PHP and poorly in JavaScript. There is probably someone more well-versed who has a better explanation.
@unshittifier
Seems like a logical explanation. Although, I still find it strange that there are no widely used packages for this problem.
I've put something together using the visitors pattern which could work for me as an OOP developer 🙂
This way its reusable and more readable than endless if-s.
@jorisvaesen Interesting approach, though I'm not sure that's better than the alternative.
Consider this TS Playground with type predicates: https://www.typescriptlang.org/play?ts=5.1.6#code/JYWwDg9gTgLgBAbzgQQB7AgZwKJStOAXzgDN8Q4ByAQ3S0oG4BYAKFYGMIA7TeYTNBhx4CAXjgAKAKYAuOAFcuAay4QA7lwCUcqXH4o6w-FDiiAfHF3AeMal3ZSIJA0NzHmbFjCgBPRKzhAuAB6YLgAOkjWQg5qGHYAC0lZBWVVDU1-FiC9Zwl+QSw3aGlNTIQAnKDOHggAGylwqREoCQADABIERpApTExqAHMpYgkuxt44+Uw4AH5Zy3DOABNdeapKQk02zQ8cmJYDoA
Maybe there's promise here, but I don't think an OOP approach is particularly elegant for the problem you want to solve.
Things that stand out are having to cast the error to fetch the message. And using type predicates to branch into the correct handler.
Personaly I'd find it preferable to make a library of common predicate-handler pairs that you could use instead of reinventing if-else chains or switch statements.
But this doesn't read well compared to statements like:
if (isErrorType(error)) { /* handling code */ }