== Quote from Dmitry Olshansky ([email protected])'s article > Honestly, I'd suggest using exceptions instead of error codes.
This seems to be an increasingly common but still expensive suggestion for error handling. Unless D has made great strides in exception performance (which is entirely possible), I still believe that, where performance is anything like an issue anyway, exceptions should be used only for truly exceptional condition--not alternate flow that could/should be expected. But I'm not just being a curmudgeon; I also have a suggestion. If you really want to take different paths based on a function return, make that return an object. This is what exceptions do, but it need not be so expensive. You could have a generic return class that has a string, a value, and casts to bool to give you most of what exceptions and bool return types give. But you can also sub-class that class and add polymorphic behavior to avoid the switch on value. Or make it a singleton and not pass it back. Or have one for each important call path, to which every called function can add delegates to run onError() or run deferred at some root level. Some of this would be a lot of work to setup, but I find it pretty generic. I should probably make a library and post it. For the stuff that most folks use exceptions for (i.e. to hold a string,) this class is easy to write, and costs must less at run-time. I will freely allow the critique that if do you this, then you'd have to check the return object after each call to see if there's error handling required. But I see this as a chief benefit for the maintainer (usually me in 6 months after I've forgotten everything about the code.) It spells out that there is another code path that's important to consider when changing things. Letting exceptions go by tends to obfuscate that. For out of memory, sure throw and don't catch. But for input string didn't parse, you want to handle that safely, informatively, gracefully, or whatever your robustness requirements are. So make it clear to someone that it needs to be handled. I see a lot of exception-unsafe code. I think programmers often don't appreciate that your function may suddenly return between any two arbitrary function calls, and almost between any two arbitrary statements. You have to really design carefully for exceptions. So it turns out this problem is a tough one and requires effort no matter what. Just a thought. Jason
