whynot include json for the cause property if you are gonna force error types on me
The cause property has a very specific purpose - it's related to preserving information about what caused the error, for example, you maybe caught one error, wish to throw another error as a result, but want to preserve information from the first error, so you make the first error the "cause" of the second error to preserve it.
That being said, you can definitely use other properties to store additional information about an error that you wish people to programmatically access, people do it all the time. I already mentioned how Node adds a "code" property to their fs errors - that's not the only property they tack on. I know the Axios library will also add information such as response headers and body to their HTTP errors, etc.
So, yes, where appropriate, many people are providing additional data on the error object. Not on the cause property specifically (unless it actually belongs there), but in other places.
1 Like
I assume what you're really getting at is this example, where you're wanting the details of the error to be available in a way a program can access?
Many authors do this kind of thing for certain errors, but there are also certain types of errors where it doesn't make much sense to do this sort of thing.
For example, what is the concrete reason someone might programmatically access the details of this error? Typically, if this sort of error happens, it's the result of a bit in the code, at which point there's not much you can do with the error besides report it. An error type isn't too important in this scenario either for the same reason, but it needs to be there due to how the language has been designed and to preserve backwards compatibility. Doesn't really hurt to have the error type either, it's just not necessary.
this is just an example, people might want to add stuff to the .info property of their custom errors
Having a standard new property to place arbitrary data is actually something that has been discussed in the past. It's a family long conversation, but it might interest you: Error "detail"
The main use case being solved there was about making it easier to build nicer error messages using arbitrary data, which is perhaps a little different than what you're going for, but I'd also be happy with simply having an official place to put data for errors. I'm probably a minority in that regard though, because as mentioned before, you can already put arbitrary data anywhere on the error object. The only benefit you gain from having an official property for it is that it removes the slight risk of the committee adding a new property to error objects with the same name you chose, which, while it probably wouldn't break your code if they do that (since your property would override theirs), it would still make the code very confusing.