+1 to making this work seamlessly, if possible. But I am not sure it is possible...
From: es-discuss [mailto:[email protected]] On Behalf Of Kevin Smith > I could, of course, do this manually: > > class ZenError extends Error { > constructor(msg) { super(msg); this.name = this.constructor.name; } > } Actually, this isn't even "correct" by ES spec standards---illustrating how error-prone this kind of manual setup is. That is, the error types in ES have `.prototype.name` properties on the constructor, not own `.name` properties. So the correct manual setup is ```js class ZenError extends Error { } ZenError.prototype.name = ZenError.name; ``` The only way I can think of to fix this is to change the `Error.prototype.name` property to a getter that returns `this.constructor.name`. But now all existing code that does *not* set `name` correctly has suddenly had its meaning, and observable side effects, changed. Seems unlikely to be web compatible. (Plus you have to create a setter and handle the cases when people *do* set it to something.) You then start thinking, well, maybe we should make a simple opt-in to the more correct behavior. But, can you really make it more simple than `ZenError.prototype.name = ZenError.name`? I guess `Error.fixSubclassName(ZenError)` is a bit more DRY, but not by much. Would be curious if anyone has any solutions, but I'm not sure there are any :(. 100% correct Error subclassing might have to remain a mistake-prone process. _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
