I’m curious how others deal with global error handling in your apps. I’m nearing the point of creating in-app error classes for various types of application errors (AppAjaxError, AppStringError, AppPermissionError, etc) and wondering if I’m overthinking my design, or if error classes are the next step of natural progression.
So let me backup and quickly cover what I have and my basic use cases.
What I have: An
Ember.onerror definition which accepts application errors and rejected promises (obviously, it’s an ember hook ). In my
onerror I do one or two things depending on the error and error type 1) Alert the user an error occurred via a service and 2) Log the error to the server.
My basic use cases: Some errors, such as exceptions and undefined state should be logged to the server and the user should be notified. Other errors, such as AJAX errors should only notify the user (server already has the log). Yet other errors, such realtime timeouts or background syncing, could be too noisy for users, but we still want to log to the server.
Normalizing: the error to present something valuable to the user. Most of the time with an AJAX error you have a nice message to give the user. But sometimes it still requires some normalization. Sometimes you have in-app validation errors, where you throw before ever hitting the server.
Promise Handling: In some cases a promise will fail with an error. A rejection handler chain to that promise might try to consume that error, say in the case of field validation it might add an error class to the associate input element. However if it can’t handle the error, it may just rethrow it to be handled later (ultimately by
So at this point I’ve shown the clear need to handle errors differently based on type and origin. Also hopefully I’ve shown that pure string errors won’t always cut it.
I’m sure many others with medium to large size apps have had this need. How did you solve it? What types of errors do you use with promise rejections? Any good general JS practices in this area?