== Quote from BCS (n...@anon.com)'s article > A possibly better solution would be to use an error handling strategy > approach, > Have the called function throw and exception supplied by the calling function. > >
I wouldn't use this, at least without a sane default exception, because it forces the caller of a function to write boilerplate for error handling (beyond what's necessary for cleanup/rollback in case of an error) even if the caller can't actually handle the errors. This severely smacks of overengineering and making the uncommon case possible at the expense of making the common case simple, and largely defeats two main purposes for exceptions: 1. Noone should have to explicitly think about how to propagate any error. One and only one level should have to think about handling it and the rest of the levels just need to be able to clean up in case of an error. 2. Exceptions are supposed to provide a sane default that's useful for small scripts (exiting the program with a decent error message). If you force the user to explicitly specify an exception to be thrown, you lose this convenience. On the other hand, if you provide a sane default exception, this might be reasonable as long as it doesn't bloat the API too much.
