Error inheritance is not working

[lazdmx]

class MyError extends Error

try
  throw new MyError()
catch e
  alert e instanceof MyError #yelds false

[epidemian]

And will probably not work any time soon i'm afraid: #2359 😔

[epidemian]

BTW, you can make it work pretty easily with class MyError extends Error then constructor -> super.

[vendethiel]

Thanks @epidemian :p.

[matthewwithanm]

@Nami-Doc @epidemian I think this might need some more attention and possibly some documentation. The code you suggest is probably not what most people want out of an error subclass…although it does satisfy the instanceof requirements, it doesn't handle arguments as you would expect. This isn't a problem with CoffeeScript per se (it's a JS quirk), but it is a problem that the only references that come up when searching for how to extend Error in CoffeeScript aren't really accurate. See MDN and these SO questions.

[epidemian]

@matthewwithanm, you're right! It seems calling the super Error constructor doesn't have any effect on the instance it receives (e.g. it doesn't set the "message" property or anything).

Would this be a correct minimal error subclass?:

class MyError extends Error
  name: 'MyError'
  constructor: (@message) ->

(it seems it does all that's expected)

Damn JS native constructors are weird! Thanks for the feedback!

I don't know where this should be documented, or even if it should be documented at all in the Coffee project (isn't it a JavaScript issue?). Maybe it could be included as a common gotcha like "why can't i subclass native objects?" or something on that vein (though i don't know how common that gotcha really is).

[matthewwithanm]

Would this be a correct minimal error subclass?

That's what I'm using. It's not really future proof (future browsers may, and apparently FF already does, accept other arguments that aren't part of the current standard), but I think it covers all real-world use-cases.

This is totally a JS issue but (IMO at least) it should be documented somewhere with the project—though this thread is already an improvement over links to the #2359 discussion (which is rather lengthy, technical, and currently doesn't have a real solution). Alternatively, we could post a new SO question (or update your original) with the proper pattern…but that's still only really useful to those who already recognize that it is a problem (as opposed to a "gotchas" note or a quick sentence warning about extending built-ins when introducing classes).

Ah, JS (: