How much defense do you put in an object with a single responsibility, keeping in mind that you're not even allowed to throw exceptions that are not thrown by the base class?
The examples on the wiki are ridiculous; parameter-checking is a general best practice. Yes, sometimes you implement a strategy-pattern as a way of "extending" the application later on.
I'm following an idea from PHP; do, or die. If the code encounters anything exceptional, an exception is raised. If it's an unexpected exception, the app will terminate. It has to, since I can't guarantee that it's data isn't corrupted at that point.
Almost no defensive programming... except if it makes my code crash sooner. (so I can find the problem more easily)
I also add some defensive programming if a poor crash description wasted my time once.
I'm more reactive that preemptive. But I always make sure that nor me, nor someone else will waste time again on the same problem.
As the in-house coder for my firm, I get asked to do a lot of ad hoc stuff, once-off applications meant to fulfil an immediate need and then never used again.
In those cases, I don't bother writing defensively. I will, however, put in an expiration date: if the application is run after that date, the app turns into nagware that reminds the user that it has expired. That is usually enough to get the user to rethink using the app, and maybe asking me to redesign it for long-term use.
I've seen screwdrivers being used as hammers so setting arbitrary limits on things that don't need limits ensures something will fail catastrophically at some future date.
It happens no matter how well you try to document the functionality. If a tool is there, it will be used in grossly inappropriate ways at some point in its existence thanks to project managers who don't know what they need and programmers who can't program[^].
Same for me and in C++, I also use compile time checking in some cases. For exemple, if the code is hardcoded for the case a constant has a given value (maybe to be more efficient), I would do a compile time check so that if the constant is changed, it would raise a compile time error...
Programming defensively for stupid users is just tiresome.
In India, you have people trying hard to break any system you give them.
Thay are not stupid. They are intelligent.
It is their way of rebelling against the system.
There are three kinds of systems: fool-proof, idiot-proof and elephant-up proof.
India is the world's laboratory for elephant-up proofing anything. Sort of like the Underwriters Laboratory in the US.
Here in Chennai, the Outsourcing Capital of the World, the Municipal Corporation computerized the property payment system.
Inexplicably, the computerized system assigned number 162-0000-025 to my friend's house. The previous number was 162-0000-000.
The guy who took in the payment of the property tax, struck out the 025 and put in 000 - the old number - and tried to apply the payment. The system moved it to "Suspense Account". This went on for 4 years. It has taken countless visits to an overcrowded central office to try to resolve the issue. My friend is out at least one tax payment.
It is a good thing that 000 was not assigned to someone else. Then my friend would have been paying somebody else's property tax and the Municipal Corporation would cheerfully have told her to contact the other person and get the money back!
A few people weren't too sure what it means, so to clarify:
Like defensive driving - always assume the worst is waiting to happen. Yes, it makes you slower, and it may be less fun, but you arrive in one piece with a low adrenalin level. I never bent a single fender, whereas the spousal unit has scrapped three (THREE!) cars because of his aggressive driving style.
here in Asia "Agile Development" pretty much equates to "Broken underfunded projects delivered in 2 months" and we're very god damn agile here in Asia, can't really afford *defensive* things. Embrace risk, code offensively! Amen!
Built-in: i choose to use C#. The choice is defensive, and works. Think: Visual Studio.
OTOH, a current project in VBA required me to build all KINDS of my own fences, error processing, and tracing mechanisms merely to maintain a sane environment. Given a choice, i will choose anything other than VBA, up to and including refusing the project.
Grace + Peace
Peter N Roth, President
Ah! See, I was thinking defensive programming would protect ME, whereas other responders are looking to protect the SOFTWARE. To hell with it, I say; it’s just a machine… but choosing the right language (whichever one keeps you most safe) is crucial. Type safety, garbage collection, Object Oriented, etc.
Grace + Peace
Peter N Roth, President
The choice of language is, to an extent, irrelevant in my
Consider what happens if you ask a user there age and they
This is not entirely true. Your example actually should show you this.
If the UI has a numeric control they can not input "Apples", only a numeric. The framework allowed it to be captured as such.
Even in the case of packaged libraries this is true. You as the user must use my IAcceptableInterface or it will not compile. I then can guarantee your object meets the constraints that I need with in my library during my compile time even though I have no idea how you are using it.
Ahhh the beauty of generic constraints and interfaces. Allows for very defensive programming and is framework specific.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.