2 Added link to Guava's recommendation against null
source | link

It's a matter of convention, documentation and use case.

Not all functions are equal. Not all requirements are equal. Not all validation is equal.

For example, if your Java project tries to avoid null pointers whenever possible (see the Guava style recommendationsGuava style recommendations, for example), do you still validate every function argument to make sure it is not null? It's probably not necessary, but chances are that you still do it, to make it easier to find bugs. But you may use an assert where you previously threw a NullPointerException.

What if the project is in C++? Convention/tradition in C++ is to document preconditions, but only verify them (if at all) in debug builds.

In either case, you have a documented precondition on your function: no argument may be null. You could instead extend the domain of the function to include nulls with defined behavior, e.g. "if any argument is null, throws an exception". Of course, that's again my C++ heritage speaking here - in Java, it's common enough to document preconditions this way.

But not all preconditions even can be reasonably checked. For example, a binary search algorithm has the precondition that the sequence to be searched must be sorted. But verifying that it definitely is so is an O(N) operation, so doing that on every call kinda defeats the point of using an O(log(N)) algorithm in the first place. If you're programming defensively, you can do lesser checks (e.g. verifying that for each partition you search, the start, mid and end values are sorted), but that doesn't catch all errors. Typically, you will just have to rely on the precondition being fulfilled.

The one real place where you need explicit checks is at boundaries. External input to your project? Validate, validate, validate. A gray area is API boundaries. It really depends on how much you want to trust the client code, how much damage invalid input does, and how much assistance you want to provide in finding bugs. Any privilege boundary must count as external, of course - syscalls, for example, run in an elevated privilege context and therefore must be very careful to validate. Any such validation must of course be internal to the syscall.

It's a matter of convention, documentation and use case.

Not all functions are equal. Not all requirements are equal. Not all validation is equal.

For example, if your Java project tries to avoid null pointers whenever possible (see the Guava style recommendations, for example), do you still validate every function argument to make sure it is not null? It's probably not necessary, but chances are that you still do it, to make it easier to find bugs. But you may use an assert where you previously threw a NullPointerException.

What if the project is in C++? Convention/tradition in C++ is to document preconditions, but only verify them (if at all) in debug builds.

In either case, you have a documented precondition on your function: no argument may be null. You could instead extend the domain of the function to include nulls with defined behavior, e.g. "if any argument is null, throws an exception". Of course, that's again my C++ heritage speaking here - in Java, it's common enough to document preconditions this way.

But not all preconditions even can be reasonably checked. For example, a binary search algorithm has the precondition that the sequence to be searched must be sorted. But verifying that it definitely is so is an O(N) operation, so doing that on every call kinda defeats the point of using an O(log(N)) algorithm in the first place. If you're programming defensively, you can do lesser checks (e.g. verifying that for each partition you search, the start, mid and end values are sorted), but that doesn't catch all errors. Typically, you will just have to rely on the precondition being fulfilled.

The one real place where you need explicit checks is at boundaries. External input to your project? Validate, validate, validate. A gray area is API boundaries. It really depends on how much you want to trust the client code, how much damage invalid input does, and how much assistance you want to provide in finding bugs. Any privilege boundary must count as external, of course - syscalls, for example, run in an elevated privilege context and therefore must be very careful to validate. Any such validation must of course be internal to the syscall.

It's a matter of convention, documentation and use case.

Not all functions are equal. Not all requirements are equal. Not all validation is equal.

For example, if your Java project tries to avoid null pointers whenever possible (see the Guava style recommendations, for example), do you still validate every function argument to make sure it is not null? It's probably not necessary, but chances are that you still do it, to make it easier to find bugs. But you may use an assert where you previously threw a NullPointerException.

What if the project is in C++? Convention/tradition in C++ is to document preconditions, but only verify them (if at all) in debug builds.

In either case, you have a documented precondition on your function: no argument may be null. You could instead extend the domain of the function to include nulls with defined behavior, e.g. "if any argument is null, throws an exception". Of course, that's again my C++ heritage speaking here - in Java, it's common enough to document preconditions this way.

But not all preconditions even can be reasonably checked. For example, a binary search algorithm has the precondition that the sequence to be searched must be sorted. But verifying that it definitely is so is an O(N) operation, so doing that on every call kinda defeats the point of using an O(log(N)) algorithm in the first place. If you're programming defensively, you can do lesser checks (e.g. verifying that for each partition you search, the start, mid and end values are sorted), but that doesn't catch all errors. Typically, you will just have to rely on the precondition being fulfilled.

The one real place where you need explicit checks is at boundaries. External input to your project? Validate, validate, validate. A gray area is API boundaries. It really depends on how much you want to trust the client code, how much damage invalid input does, and how much assistance you want to provide in finding bugs. Any privilege boundary must count as external, of course - syscalls, for example, run in an elevated privilege context and therefore must be very careful to validate. Any such validation must of course be internal to the syscall.

1
source | link

It's a matter of convention, documentation and use case.

Not all functions are equal. Not all requirements are equal. Not all validation is equal.

For example, if your Java project tries to avoid null pointers whenever possible (see the Guava style recommendations, for example), do you still validate every function argument to make sure it is not null? It's probably not necessary, but chances are that you still do it, to make it easier to find bugs. But you may use an assert where you previously threw a NullPointerException.

What if the project is in C++? Convention/tradition in C++ is to document preconditions, but only verify them (if at all) in debug builds.

In either case, you have a documented precondition on your function: no argument may be null. You could instead extend the domain of the function to include nulls with defined behavior, e.g. "if any argument is null, throws an exception". Of course, that's again my C++ heritage speaking here - in Java, it's common enough to document preconditions this way.

But not all preconditions even can be reasonably checked. For example, a binary search algorithm has the precondition that the sequence to be searched must be sorted. But verifying that it definitely is so is an O(N) operation, so doing that on every call kinda defeats the point of using an O(log(N)) algorithm in the first place. If you're programming defensively, you can do lesser checks (e.g. verifying that for each partition you search, the start, mid and end values are sorted), but that doesn't catch all errors. Typically, you will just have to rely on the precondition being fulfilled.

The one real place where you need explicit checks is at boundaries. External input to your project? Validate, validate, validate. A gray area is API boundaries. It really depends on how much you want to trust the client code, how much damage invalid input does, and how much assistance you want to provide in finding bugs. Any privilege boundary must count as external, of course - syscalls, for example, run in an elevated privilege context and therefore must be very careful to validate. Any such validation must of course be internal to the syscall.