Programming when expecting that the caller will have bugs or malicious intent

[tothambrus11]

When doing inter-process communication, e.g. making a web request, or just controlling a service with high availability, we must write a boundary where all precondition violations of our core function is signaled to the caller as an error instead of crashing the process.

E.g:

• A web server must handle a deletion request for a missing item, even if the core data model has a precondition for deletion that the ID must exist.
• A robot's sensor must handle invalid packets.
• Win32/POSIX API must not crash the kernel if the user calls the functions wrong.

I'm starting to think that offensive programming is useful within a bounded context, but between bounded contexts, sometimes we may need to ensure that none of the functions have preconditions not enforced by the type system. In particular, a bug in a caller that's in a different process shouldn't crash the currently running code. (The property may be useful even within a single process, but I haven't found a good example yet. Maybe if the callee is so rapidly evolving that specifying its preconditions wouldn't make sense and the user should just expect different errors coming out from time to time.)

What other cases are there when we need to eliminate preconditions / convert them to errors? How would you think about these?

[dabrahams]

If you are signaling an error it's no longer a precondition. You've just misclassified the condition.

[tothambrus11]

Good point, thanks!