I have a question about the idea or decision of JavaScript that JavaScript supports exceptions but the base class is Error
. I feel like very strange because most people think that
-
Error
means something we can (should) handle or assume it may happen often
-
Exception
means something we cannot handle or we don't try to handle
Based on the idea, I think Error
class should be Exception
.
Could you suggest references about the argument of this kind of decision?
I think in JavaScript the two terms are interchangeable. I don't completely agree with the two points personally (i.e. I don't think errors happen often, and we should definitely handle them if we anticipate them. The same goes for exceptions). Either way, since the Error
class is used for both errors and exceptions (if there even is a well-defined separation between the two) renaming it from one to the other doesn't seem all that useful. Even if we wanted to start using Exception
instead of Error
, we would keep Error
around for backwards compatibility, and given they function identically (correct me if I'm wrong) people will probably go for Error
more often because it's just shorter.
huh. I've always heard it the other way around.
- Errors are for programmer errors, which you shouldn't try to recover from, but you may wish to catch it for logging or displaying purposes (i.e. passed an int to a function expecting a string, or the program is in a bad state).
- Exceptions are used for the non-main code paths, that the API user may wish to still handle, like a file-not-found exception.
And, it does seem that javascript is modeling it after this pattern, like you said. The DOMExceptions are for non-fatal errors that you may wish to explicitly handle, while a TypeError normally indicates a programmer error.
I know in Java it's this way. Not sure about other languages.
I do also agree with @vrugtehagel - we often use these words interchangeably in javascript. It does seem javascript's core libraries follow a naming convention that distinguishes the term "error" from "exception". Often, userland code doesn't follow this same naming convention, nor is there much incentive to do so. If you're in userland code and want to throw a generic error that's not meant to be caught (except for logging purposes, etc), then just throw an instance of "Error", otherwise, subclass it so that it can be caught and distinguished from other error types. when following this pattern, there's no real need to make a distinction between these two terms.
I think the meaning of "error" and "exception" is really just a language-specific thing. Some languages have chosen to make a distinction while others don't. Javascript doesn't (except for the naming convention its core libraries follow). It looks like python doesn't either - even their core libraries don't seem to make any distinction to the meaning of those two words.
Thank you @vrugtehagel and @theScottyJam.
This kind of discussion / hearing opinions is what I wanted.
I've checked some articles that mention the separation between exception
and error
and I thought what I wrote in the first post was a popular understanding but as @theScottyJam mentioned, it seems unclear or controversial. I mean there isn't any absolute position we can easily agree with.
I agree with the idea that the name is just a name because when it comes to component-based systems which means the systems have separated responsibility, errors
/ exceptions
simply means the incident was not handled in the separated system and it depends on how it is handled in the upper system or the system that requested something to another system.
Thanks.
1 Like
Python makes some distinction at the language level - errors are generally fatal, while exceptions are not.