Question about error handling design
BlitzMax Forums/BlitzMax Programming/Question about error handling design
| ||
| Okay, I'm working on my modular logic/behavior system, where you code your behavior as an object that can then be attached to any behavior enabled object in the game, including other behaviors. Anyways, one of the design goals is extreme customizability and flexibility without having to modify any of the framework or structure code (i.e. if you want to modify something, you simply write new code and change a function pointer and voila). So, anyways, I'm trying to think of the best approach to error handling. Right now this is what I'm thinking, although maybe it's overkill...lemme know what you think: Each behavior is a standalone object. Each behavior can have it's own error handler. Each behavior belongs to a parent object (which may be another behavior, but for the sake of this discussion, assume it's a sprite object or something). These behavior enabled objects are quite flexible. They also can have their own error handler. Whenever a behavior signals an error, it first looks at it's own error handler to see if it can handle the type of error specified. If not, it passes the error along to it's parent object. If it doesn't have a parent object, it passes the error to the global error handler. If the behavior CAN handle the error, it can do whatever it wants with the error. It could look at the error and try to resolve it, and then after deciding it can't be resolved or can only be partially resolved, it might change the error data and then pass that along to it's parent object, allowing the error to propagate forward in hopes that it will be fixed/logged/dealt with appropriately. If the behavior can't handle the error, it passes it to it's parent. Lastly, a behavior can contain functions that it "registers" with it's parent object. The parent object receives and registers these functions in it's own error handler, and then the parent objects handler can now deal with these kind of errors. This would be handy in the case where you have something like this ..............Parent |-----------|-----------| child1 child2 child3 Now, assume child 1,2 and 3 all can throw a "Can't retrieve necessary data" error, and then they also package along some data describing the missing parameter. However, whoever coded child1 and 2 didn't actually set up anything to handle the error. So you come along and code child3, and include an Error Function that logs this "can't retrieve necessary data" error. Well, you can then simply attach child3 to the parent, and register that function with the parent (you can do this in code or set up code so that it's possible to do this during runtime), and now the parent object can handle the errors thrown by child1 and child2. Maybe this is too compllicated, but I'd like a nice and thorough error handling system to make debugging any weirdness with this behavior system a breeze. So I figured a nice and modular error handling system would help achieve that end. The idea is that if people establish some commonly seen errors and stick to a given naming convention, people could code error handlers as just another "behavior module" and then you could just copy + paste someone elses error handler behavior into your code, attach it to some objects, and voila, it would "just work (tm)." |
   |