4 ms·
No, I want dedicated classes. Be they thrown or returned as a value. Error codes are limiting and serve a different purpose. Error codes contain only the type
by RadiozRadioz 1y ago
No, I want dedicated classes. Be they thrown or returned as a value. Error codes are limiting and serve a different purpose.
Error codes contain only the type of error that occurred and cannot contain any more data. With an error class you can provide context - a 400 happened when making a request, which URL was hit? What did the server say? Which fields in our request were incorrect? From a code perspective, if an error happens I want to know as much detail as possible about it, and that simply cannot be summarised by an error code.
If I want to know the type of an error and do different things based on its type, I can think of no better tool to use than my language's type system handling error classes. I could invent ways to switch on error codes (I hope I'm using a language like Rust that would assert that my handling of the enum of errors is exhaustive), but that doesn't seem very well-founded. For example, using error enums, how do I describe that an HTTP_404 is a type of REQUEST_ERROR, but not a type of NETWORK_CONN_ERROR? It's important to know if the problem is with us or the network. I could write some one-off code to do it, or I could use error classes and have my language's typing system handle the polymorphism for me.
Not that error codes are not useful. You can include an error code within an error class. Error codes are useful for presenting to users so they can reference an operator manual or provide it to customer support. Present the user with a small code that describes the exact scenario instead of an incomprehensible stack trace, and they have a better support experience.
Side note: please don't use strings for things that have discrete values that you switch on. Use enums.
- mirekrusin 1y agoYou need some kind of grouping otherwise any simple action ie. involving single io would require handling of dozens different classes.
- RadiozRadioz 1y agoYes of course. That's why I mentioned polymorphism. A FileNotFoundException and NoDiskSpaceException can inherit from IOException for example. With polymorphic error classes, a caller can decide if they want to handle the different cases individually, or just catch the overarching IOException. All this flexibility comes for free when your use your language's type system, whereas with plain error codes you would have to implement grouping yourself manually with some kind of lookup table.
- mirekrusin 1y agoThis classical, rigid OO way of thinking assumes there is single inheritance chain but that's not the case more often than not. For example i/o can have hierarchy based on operating system, kind of i/o (network, filesystem etc), access type (read/write), nature (idempotent etc), severity, abstraction (hardware, os, library, app levels), source (calee/caller errors or input/configuration/external service errors) etc.
- RadiozRadioz 1y agoOk, then use traits or composition instead of inheritance. Still using the type system, still better than hardcoding a complicated error code mapping system. I used inheritance as an example, my main point is to use the type system when dealing with... types of things.