1. 5
  1.  

  2. 6

    I think this is a misguided blaming of the language when the programmer is at fault. If you are catching an exception in JavaScript, verify the type of exception before continuing. This is just a straightforward necessity when you don’t have a language with static types.

    So there are two programmer errors in the example: the typo of ‘sedn’ and the absence of a branching for the ‘nouser’ exception.

    I get that it’s not fun and the overall point is that JavaScript should handhold the programmer a bit better, but hey, it’s JavaScript and we’re used to Stockholm syndrome.

    1. 4

      In Python and Ruby the popular linters will point this kind of code out for catching all exceptions. There’s got to be an equivalent in JS.

      1. 1

        I think verifying the type of the exception is difficult in practice. It is not a uniform practice to use granular “subclasses” so the instanceof operator can’t really help with application-specific or library-specific errors. You end up with very ad-hoc set of codes or flag properties that are just in no way comprehensive, stable, or reliable. I think the best you can do is what bounce does which is detect the 6 known programmer errors, but now we’re basically accepting the fact that what javascript itself provides is just not sufficient to properly categorize.