I've written an API which can be configured to signal errors in different ways (return values, debugging messages, or exceptions). I've got a check in place when the API is first initialized to see what type of error handling the client is requesting - what should I do when they request an undefined error handling type?

This is kind of similar to "Where do I log the error that I can't write to the logfile?"

Do I go with the idiom of the language, do I fatal? Do I throw an exception, even though if they aren't asking for exception handling they probably haven't wrapped the call in a try/catch? The language I'm writing doesn't have an ENUM type so it can't be a type error.


1 Answer 1


I see only a couple of choices:

  • Assume the most common default and use it
  • Crash (fatal error / configuration error)
  • Walk through your different options until you find one that works (i.e., if the most common default is 'write to file' and you don't have a file name, keep falling back to different options until you get to one you know works)
  • Use all available options at the same time (i.e., throw a config error AND return and error code AND write to the console AND ...)

Personally, I'd probably crash with a fatal configuration error, but your situation may be different.

  • I was wavering on that, but I think fataling is the way to go here, based on the context Jul 30, 2013 at 16:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.