error.name leads to disasters with readability because, it lets programmers get away with unreadability.
//no fix
try{
['a'].forEach('a')
}catch(err){console.log(err.name)} //"TypeError" (duplicate info)
//with fix
try{
['a'].forEach('a')
}catch(err){console.log(err.name)} //undefined
Hi,
Not getting what you mean by 'get away with' here. What's the readability aspect? Why is the ability to check name increasing unreadability?
Also bear in mind name and the error class name do not always have the same value, e.g. when you subclass Error and don't deliberately set name.
(Vanishingly unlikely that the name property would be removed for built-in error classes, unless there were a security implication.)
replace the error name with a property called Error.info to where you get parseable information about the error
try {
['a'].forEach('a')
}catch(err){
console.log(JSON.stringify(err.info))/*{
value:"a",
type:"string",
supposedType:"function"
}*/
}
OK, see what you're driving at here. Though unsure where the conventional meaning of code readability comes in.
Either way I don't see it as likely that someone would work with these kinds of structured Error.info objects as-is. Seems to me they'd end up being sprintf'd in reality, which is what Error.prototype.toString() already does. The JS object is somewhat readable, but surely not as easy to follow as the message constructed by the engine.
Can you nominate some other languages where the individual components of an error - the args passed to sprintf, basically - are available in userland? I guess if the app you're building is specifically a debugger/analysis app, i.e. analyzing 3rd party code, it could be useful to see how frequently a certain type mismatch happened.
Further reading: GitHub - tc39/proposal-error-capturestacktrace: Standardizing Error.captureStackTrace
You're free to make an Error that has that information, but not all exception scenarios can provide data like that.
Either way, .name can literally never be removed, because it would break the web.
change it to .constructor.name and hide it from code using the stringified version and the console
the engine might need some fixing, plus Error.info could be pretty useful for handling errors because, it will basically be .message but for code instead of the user
It can't be changed, EVER, or existing code would break.
make err.name be the same as err.info.errorName||err.constructor.name
and err.name= be the same as err.info.errorName=.
Also plz deprecate .error but, never remove it
Why would that solve the problem you mentioned at the beginning? Surely everyone will reach for the reliably present .name instead of something deeply under .info.
make .name get the value under .info.errorName when accessed, plus .info.errorName might not be present so, if its not there, just use the class name for the value until .name or .info.errorName is set
I'm not asking how to technically achieve it - there's lots of ways.
I'm asking how that solves your actual problem. Perhaps it would help if you restated the problem without talking about a potential solution?
error types seem unnecessary for people if the message conveys whats wrong
Wouldn't it be better to add the additional information to .cause?
Proposal: Enhanced Network Error Handling Using Error.cause - 
Ideas - TC39
yes
error types seem unnecessary for people if the message conveys whats wrong
Is this specifically an issue with the "name" property, or do you dislike the idea of having different error types in general? Assuming it's the latter...
The usefulness depends on the nature of the error.
For example, if I'm using Node and am trying to open a file, but the file does not exist, it's going to throw a very specific error that I can catch and programmatically handle. In Node's case they choose to attach a "code" property to the error for me to inspect, but they could have subclasses ”Error" as well, and then I would check if the error thrown is of the type FileNotFound. Either way, I don't want my code trying to inspect the error message to figure out if it was a file not found error or something else - that's very unreliable, I need some kind of error type to check.
only code and programmers should be able to read it, not users using inspect element
That's not really viable; it's a web principle that the user of a browser is in control.
"inspect element" is a tool designed for programmers, so if programmers are allowed to see it, it makes sense to show it in the dev tools console. In fact, it's very important that the error type is displayed there - for APIs that aren't documented very well, seeing the error type in the console is an invaluable way for the programmer to learn how to adjust their code to catch that error type.
The end user using the webpage normally (not using dev tools) shouldn't need to see that error code (except, perhaps to report that information in a bug report). But that's on the webpage author to omit that information when displaying errors to the end user.