#📚reference This concept plays a key role in enforcing the [[security]] and [[reliability]] of computer systems. In a nutshell, defensive programming accepts the fact that all programs will eventually fail. The question is: What would happen next? Would failing to fetch the client's profile crush the entire website, or will we just return a meaningful error? By assuming that everything that may return an error will eventually return it, we can teach our system to restore after failures. Another side of defensive programming is both pessimistic and full of respect for human dignity at the same time. The pessimistic version sounds the following: > Under any circumstances, we should assume that among thousands of honest users, a few will always try to exploit us and other well-behaved people. But the respectful tells: > We've built something for people to use. How are they going to use it? In any possible way! Let's assume that people who use our programs are infinitely creative and incredibly playful. The conclusion is the same: we are responsible for handling incorrect user inputs. If someone uploads a file that may fill the entire storage space, then it's we who should check the size of this file and stop downloading when it exceeds the allowed limit. Defensive programming can be applied even to user interfaces and [[user experience]]. What should happen when a user submits invalid data in one field of a survey? Should we show a terrible black screen and erase all their entered data, or keep the correct data somewhere safe, restore them, and gently ask the user to correct their input? While defensive programming is an attitude, not an algorithm, some programming languages can be exceptionally helpful. For example, Rust has [`Option`](https://doc.rust-lang.org/std/option/enum.Option.html) and [`Result`](https://doc.rust-lang.org/std/result/enum.Result.html) types that allow the encoding of abnormal or undesired output. Go has its own idiomatic [error handling](https://go.dev/blog/error-handling-and-go). Basically, all modern statically typed languages* adopted such constructions in one way or another. With proper tools, this paradigm doesn't look completely defenseless. --- `*` No, TypeScript is not a properly statically typed language. --- <font style="color: #F86759">Contributors:</font> *[[Mykhailo]]* <font style="color: #F86759">Last edited:</font> *2024-03-27*