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?
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.
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.
Although, I have posted the answer in stackoverflow site, that might be still helpful to post here.
When you want to stop the program immediately rather to proceed with an unwanted state. This is often related to the philosophy of the Fail-fast [ 1 ] system design.
When there are certain possibilities of cascading failures (i.e. in microservices) for the first unexpected condition that might lead the application into severe inconsistent or unrecoverable states.
When you want to detect bugs in your system exclusively in the debugging period. You might want to disable them in production if language supports.
When you already know that the unexpected conditions arose due to your internal miss-implementation and external system (i.e the callers) has no control over the unwanted state.
When you know that the unexpected conditions arose due to external systems fault (i.e. wrong parameters, lack of resources etc).
When you know that the conditions can be backed up with alternative paths keeping the application functional qualities still intact (i.e. might work well for another call with proper parameters from the caller or external system).
When you want to log and let the developers know about some unwanted state but not a big deal.
Note: “The more you use assertions, the more robust system you get”. In contrast “The more you use exceptions and handle them, the more resilient system you get“.
[ 1 ] Fail fast - In systems design, a fail-fast system is one which immediately reports at its interface any condition that is likely to indicate a failure. Fail-fast systems are usually designed to stop normal operation rather than attempt to continue a possibly flawed process. Such designs often check the system's state at several points in an operation, so any failures can be detected early. The responsibility of a fail-fast module is detecting errors, then letting the next-highest level of the system handle them.
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.
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.
This is language-agnostic but I will make two assumptions, here:
I basically agree with most of the other answers: assertions should always be used to check for bugs (stating assumptions) and never to check for things that are outside of your own control, like e.g. user input.
So, by extension, exceptions (or general error handling) should handle everything that could go wrong as a matter of course.
But I don’t necessarily think that only assertions need to be used to check assumptions; you might sometimes want to use exceptions for that. Why? Because of point number one: assertions might be disabled. So you might want to use exceptions for, say, stating assumptions that never should be violated, no matter what kind of build or runtime configuration you are using.
So what’s the sweet-spot for assertions? Well, it seems that assertions are enabled and disabled based on two criteria: (1) the cost (performance-wise) of the check and (2) whether one should crash when the assumptions are violated or whether one should do something less intrusive and simply carry on, like for example just log the error. But recall point number two above: we assume that we can catch assertion errors (like catching AssertionError in Java). So let’s for simplicity’s sake assume that we can catch and log (i.e. not crash) assertion errors if we want.(†1) Then it seems that perhaps the sweet-spot for assertions are checks that you might not always want to run based on their cost. So use assertions for things that you might want to sometimes disable. Maybe you for example want to:
Or whatever other scheme you want to use.
Or if you can’t catch assertions then you can implement something like assertOrLog() which crashes when asserts are enabled or logs the error if not:
// Java
assert false : errorMessage
log.error(errorMessage);
