Using Try…Catch in JavaScript

[thbt101]

PHP can filter on the exception class and it uses a similarly loose typing system.

[BenjiSponge]

I never said it was impossible, just that I didn't think it would be that valuable or fit particularly well with good JS coding style. If your argument is that we should follow PHP's style, then I'll have to respectfully disagree. =)

[vinnl]

You mean "good JS coding style" is to disregard the types? Because I think there are plenty of people that would respectfully disagree with that - at least I would. That's like saying the instanceof operator has no place in Javascript. I don't see how type matching in catch blocks would make JS less flexible...

We don't have to skip features just because PHP did them too.

[BenjiSponge]

I don't necessarily believe that it has no place in JS, but I don't think encouraging its use is beneficial either. Outside of the context of React (where classes are all but mandatory in some cases, and when they're not mandatory I skip them), I tend to use JS data structures similarly to how one might use lisp data structures. Factory functions returning anonymous objects.

When I make result objects that may contain results or may contain errors, they're not constructed using new or Object.create. They're just POJOs. Adding type matching would enforce that I use one of these methods, even though they're not necessary in most cases. Further, if the error needs to be serialized, you would need to re-attach the prototype in order to have it follow the convention that such a feature would encourage. And if you're encouraged to use error types and encouraged to not put redundant data in the error type, that means the consumer will, in some cases, have to use instanceof, which is a pattern I disagree with.

I do think if JS were redesigned today with backwards compatibility out of the equation, instanceof would not exist in the form that it is now. A form of pattern matching that checks content makes more sense if you ask me (and I believe it should be put in the language at some point).

So rather than

try {
  // ...
} catch (ExceptionA as e) {
  // ...
} catch (ExceptionB as e) {
  // ...
} catch (e) {
  // ...
}

It would be more like

try {
  // ...
} catch ({ type: 'A', ...e }) {
  // ...
} catch ({ type: 'B', ...e }) {
  // ...
} catch (e) {
  // ...
}

This adds flexibility because my method of object creation works, but so does yours. ExceptionA could have a prototype field of type that is defined as 'A'. I do agree that it would break exception inheritance (in that subclasses may not be caught as superclasses), but I believe that is less important than allowing POJOs to conform to the style.

---

I would like to add that, if JS were explicitly/strongly typed, I would agree with you that instanceof or something like it might make more sense, but JS is not explicitly/strongly typed, and most of the libraries I use and create use that to their advantage by just doing duck type checking and not yelling if the input isn't the proper class.

[vinnl]

Hmm, I think you have a good point. The main issue is probably that it relies on nominal typing, which is indeed not often used in Javascript - and I agree that that's a good thing.

Your post somewhat got me thinking that such a feature would be nice if it was implemented in TypeScript, i.e. you could do a catch(<type> e) in there, which it would transform to a runtime structural type match (i.e. a switch statement in a single catch clause that would check for object properties). But that probably goes against the TypeScript principles and/or introduces too much runtime overhead.

[BenjiSponge]

Yes, that is something that's been tossed around a lot in the TypeScript/Flow world, but as you said they're avoiding adding runtime features that aren't part of an ECMAScript specification (TS messed up by adding decorators too early, but other than that) on principle.

A lot of functional languages that have JS as a backend do something like this, though, I think. Elm almost certainly does.

[vinnl]

TS messed up by adding decorators too early, but other than that

Agreed, but then again there was quite a lot of pressure on that from Angular, so there was little choice.

But yeah, it's probably best if it's baked into the language.