Point taken. I was thinking about stuff like a validation function, which in this model would be about three steps down the call chain from the client's get() call. Code like that would be designed to fail at specific times and for specific reasons, and is the best source for information about which zero/one/many conditions the input failed to meet.
Silent-on-success/noisy-on-failure is conceptually similar to throwing an exception. The code up the call chain that tests/reads the result string is vaguely like a series of exception handlers. You do have to organize the code a little differently, walling off any code that shouldn't execute with bad data behind a conditional, but in most cases that isn't too difficult. The main trick is to avoid putting a big list of things that can fail all in the same function.
I generally solve that problem by iterating over a list of function pointers and dropping out of the loop if something fails. And whenever possible, I prefer to run the whole loop, collect all the errors, and then proceed or exit based on the existence/nonexistence of one or more failures. That keeps me from ripping out what little hair I have left because of the old, "okay, I solved the problem that made the code choke there, and now it's choking in the next condition three lines further on," scenario.
Sometimes you do run into logic that requires exceptions, but this works pretty well for me most of the time.
The overloaded FALSE string does sound like fun, though.. I may have to play with that one of these days when I'm feeling silly.
In reply to Re^4: Need help with a conceptual speed bump
by mstone
in thread Need help with a conceptual speed bump
by mstone
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |