

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer

Often when I write a functions I want to make sure the inputs to it are valid in order to detect such errors as early as possible (I believe these are called preconditions). When a precondition fails, I've always thrown an exception. But I'm beginning to doubt whether this is the best practice and if not assertions would be more appropriate.

So when should I do which: when is it appropriate to use an assertion and when is it appropriate to throw an exception?

share|improve this question
I think this question should be asked on stackoverflow, though it has probably been asked a dozen times there, so you might already find many answers there. – user281377 Oct 29 '10 at 9:05
up vote 35 down vote accepted

Assertions should only be used to verify conditions that should be logically impossible to be false (read: sanity checks). These conditions should only be based on inputs generated by your own code. Any checks based on external inputs should use exceptions.

A simple rule that I tend to follow is verifying private functions' arguments with asserts, and using exceptions for public/protected functions' arguments.

share|improve this answer
Good point about using exceptions for external inputs. I'd also add outputs to that too - problems when trying to create/write to file/database etc. – ChrisF Oct 29 '10 at 10:12
And inevitably you'll find those assertions being triggered in production. +1 for verifying private stuff with asserts! Maybe you could say "use asserts when you are in full control of the inputs"? – Frank Shearar Oct 29 '10 at 10:40
In java, at least, you have to typically enable the assertion check with the -ea command line parameter. This means assertions are effectively no-ops, unless you explicitly turn them on. – Bill Michell Mar 9 '12 at 13:11

Assertions are used to find programming errors. Your programs must work just as well when all assertions are removed.

Exceptions, on the other hand, are for situations that can happen even when the program is perfect; they are caused by external influences, like hardware, network, users etc.

share|improve this answer

Typical programming practice is to compile out assertions from production/release builds. Assertions will help only during internal testing to catch failure of assumptions. You should not assume the behavior of external agencies, so you should not assert on events from the network or user. Also it is a good practice to write handling code for production builds in case an assertion fails.

For example in C,

int printf(const char *fmt, ...)
  assert(fmt);  // may fail in debug build but not in production build
  if (!fmt) return -1; // handle gracefully in production build

Exceptions are meant to be built into production builds. The alternative for exception is returning error and not assertions.

share|improve this answer
I don't think it's a good idea to put graceful behavior behind an assert for the same condition. Inevitably, because the graceful behavior only exists in the production version, the code that was supposed to deal with the graceful behavior will be poorly tested and crash just as bad as, if not worse than, the code would have were it not guarded. – Sebastian Redl May 3 '13 at 16:37

One problem with asserts for me is that they are disabled by default in Java.

We use a fail-first strategy where the program - which may have been running unattended for years - needs to crash as early as possible to avoid data corruption in case of bad data (on an unexpected form). This is what we use the checking for, and by using asserts we basically risk them not being active.

share|improve this answer

Your Answer


