![]() Since these are "expected errors", we don't want to create a lot of noise in the logs just because the application is doing "what it's supposed to do." This leaves the "unexpected errors" as the primary entries within our log aggregation.īeyond this, we have very little consistency in how we throw errors. This level doesn't get sent to our log aggregation service unless our "Debug Logging" feature flag is enabled in production (or the error is allow-listed). ![]() When we catch and log these errors - the ones that start with InVisionApp. This allows us to quickly differentiate errors that we throw explicitly from the errors that are thrown through other means (such as infrastructure, networking, and database errors). And it's that every error that we throw in our ColdFusion application has to start with the prefix: InVisionApp. I need to develop a standard that I can adhere to such that I can focus on the business logic and not get distracted by the less significant details.Īt InVision, we do have one standard when it comes to throwing errors. As such, every time I go to throw an error, I'm left feeling very shaky about the whole thing. But, I've never put much thought into an error type schema or a naming convention for the errors that I throw() in my ColdFusion applications. Over the last few years, I've spent a lot of time thinking about error chaining, the difference between throwing errors and reporting errors, and a general set of DOs and DON'Ts for managing errors in an application.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |