Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
Assume a default. – Robert Harvey Jul 30 '13 at 15:42
up vote 4 down vote accepted

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.

share|improve this answer
I was wavering on that, but I think fataling is the way to go here, based on the context – Jonathan Rich Jul 30 '13 at 16:01

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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