3

I took a PHP test for NASA recently and thought I should have done better. I believe the issue is something I used to know about, but need a refresher in. I can't remember what it is called though. It is the concept that you have to check for null, empty, and edge-cases. No, it's not unit testing or anything like that. It is a programming technique involving conditionals, equality, and existence tests, and then handling error exceptions.

Does anyone know what the web-searchable, hash-taggable, technical term for this technique is?

11
  • 5
    Your description sounds somewhat contradictory. Checking for null references doesn't sound proactive at all to me, but purely reactive. Proactive would mean to never have null references in the first place. – Jörg W Mittag Jan 29 at 10:18
  • 1
    I have edited the question and removed the word "proactive" trying to not lure opinionated answers. Hope it helps. – Laiv Jan 29 at 10:35
  • 2
    Checking for nulls and edge cases is definitely not restricted to OOP, I took the freedom to edit the question accordingly; this does not seem to invalidate the current answer. – Doc Brown Jan 29 at 15:01
  • 3
    It can go by many different names, but these are all examples of needing to do input validation. – rwong Jan 30 at 4:26
  • 2
    I agree that defensive programming is the right topic. I also agree that input validation covers what you mention. See also fail-fast, and contrast offensive programming and exception handling. You might also find Circuit breaker design pattern interesting. – Theraot Jan 31 at 15:24
10

It's part of defensive programming, but that may encompass many other things:

Defensive programming is a form of defensive design intended to ensure the continuing function of a piece of software under unforeseen circumstances. Defensive programming practices are often used where high availability, safety, or security is needed.

Defensive programming is an approach to improve software and source code, in terms of:

  • General quality – reducing the number of software bugs and problems.
  • Making the source code comprehensible – the source code should be readable and understandable so it is approved in a code audit.
  • Making the software behave in a predictable manner despite unexpected inputs or user actions.

(source: Wikipedia)

12
  • 1
    The OP is asking for a "proactive" approach though, whereas I would argue defensive programming is very much reactive. Proactive to me would mean making sure that you never have null references in the first place. Design-by-contract, static analysis, or choosing a different programming language would be more proactive, I think. – Jörg W Mittag Jan 29 at 10:16
  • 3
    Like your comment under the question, I don't think that his and our definitions of the word 'proactive' coincide. – Glorfindel Jan 29 at 10:23
  • 2
    @JörgWMittag I somehow agreed with Glorfindel. When you say reactive, what do you mean? What makes defensive programming or checking nulls to be a reactive approach? Because we have allowed nulls to happen due to a wrong decision or flawed design? – Laiv Jan 29 at 10:27
  • 1
    @EricHepperle-CodeSlayer2010 I have no idea. I only use PHP when forced to, and I have some control over the input (and hence defensive programming is less necessary). But 'security' often covers things like SQL injection, XSS and other hacking tricks. – Glorfindel Jan 29 at 10:43
  • 2
    A defensive driver is someone who doesn't hang their personal safety on the assumption that others will operate their vehicles correctly. A defensive programmer is someone who doesn't hang the safety of their code on the assumption that other parts of the system will behave correctly. If you are assuming the caller won't pass you a null when they're not supposed to, you're doing it wrong. People make mistakes. If you program defensively, you prevent their mistakes from propagating to other parts of the system in an unpredictable way. – John Wu Jan 30 at 6:51
3

If you are referring to a particular check, that is usually called a “guard condition”, if you are talking about using guard conditions that would be defensive programming.

Some languages have ways to embed particular types of such checks in the language, which is typically done through the type system. For instance C# allows you to create a variable where the type is a non-null string. Pascal allows you to declare a type where the underlying value is an integer between 18 and 120.

1
  • Another related concept is the Interface Contract (Bertrand Meyer, 1986). – James Youngman Jan 31 at 9:49
2

If a function argument can be null, but is never supposed to be null, you have three choices: a. You ignore this and whatever happens, happens. B. You check and if the pointer is null you report an error, throw an exception, kill the program, whatever seems most appropriate. C. You check and if the pointer is null you muddle through as best as you can. C. would likely be called “defensive programming”

You decide on a case-by-case basis what to do. Usually you look at it from a higher level where you decide “if this pointer, which should never be null, ends up being null, what’s the best thing to do”. During development the best would often be to fall into the debugger so the developer can figure out why the pointer is null and fix the problem. In production you need to decide intelligently what to do. In many situations it’s better for a program to crash than to give wrong results.

PS. In C++, a null reference is undefined behaviour. For example "int* p = NULL; int& r = *p;". Since it is undefined behaviour, checking that an int& reference that your function received is a null reference won't necessarily work. The compiler can say "null references are undefined behaviour, therefore there are no null references, therefore a check if (&r == NULL) is assumed to always fail". In Java, references to objects can be nil so you can check for it.

Xcode + Clang in C and C++ have an interesting feature: Since they don't know if a pointer argument is allowed to be a null pointer or not, they assume that the caller passed in a non-null pointer to avoid gazillions of warnings. But once you check whether it is null, the compiler assumes it can be null (or why would you have checked?) So

if (p == NULL) printf ("Error, p is null\n");
*p = 1; 

will give you a warning. Without the p == NULL check, no warning.

4
  • 1
    You check and if the pointer is null you muddle through as best as you can. Honestly, I'd call that offensive programming - as in offensively bad programming. That's probably the worst thing you can do if you find an argument with a value it's never supposed to have. If x is never supposed to be null but you get a null value for x, by continuing you've just silently propagated a bug further along. That's how you wind up with systems that have nine 5's for reliability... – Andrew Henle Mar 21 at 13:28
  • Andrew, this is where you post your alternative that i didn’t mention. So there’s a fighter pilot under attack, and a null pointer comes in. What would that fighter pilot want you to do? – gnasher729 Mar 21 at 14:37
  • @gnasher729 As if any of us are writing jet fighter code. Yes, there are rare exceptions (also medical devices) where crashing is ugly. But too often programmers follow the PHP Fractal of Bad Design philosophy: "When faced with either doing something nonsensical or aborting with an error, it will do something nonsensical." – user949300 Mar 21 at 15:03
  • @gnasher729 Replace "fighter pilot under attack" with "Boeing 737MAX right after takeoff" to get a better feel for the consequences of propagating a bug because you write code to low standards. You already covered the alternatives: you return an error or throw an exception. Ignoring the problem totally or trying to keep working despite an out-of-spec input not only allows the bug to continue to exist but expands its impact. How is that a good idea? – Andrew Henle Mar 21 at 15:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.