It's important to separate coding mistakes from exceptions. For exceptions, I define my own classes derived from the Error object and I give each one a unique `

It's important to separate coding mistakes from exceptions. For exceptions, I define my own classes derived from the Error object and I give each one a unique `name` property that way the error handler can decide how to handle the error based on its name. If the error happens on the server but is also meant for the client side (and is human-friendly), then I may add an `error.isClientError = true` property; then, in my catch handler, I know that these kinds of errors are safe to send to the client. Of course, it takes some discipline to come up with a consistent and well defined error-handling strategy, but IMO it is not difficult. Also it's not a problem if a third-party library doesn't agree with your error-handling approach, it's often a good idea to re-create and re-throw errors from third-party libraries to provide more context anyway. That said a lot of JS libraries do use a similar approach as me for error handling, but sometimes they might use an error.code property instead of error.name but it doesn't really matter. The worst is if a third party library throws plain strings, but that's also often not a huge problem either because my own logic can make sense of the context and re-throw a proper SomeThirdPartyLibraryError which incorporates the original error string; it's just a little bit of extra work.