null object swallows calls - good idea?

often you have to explicitly test whether something is null before you try to use properties or methods of it, otherwise you will get some kind of error (java: NullPointerException, javascript: ReferenceError)

in other languages the call is just ignored (objective c, i think)

in others (coffeescript, groovy), there is a "safe access operator" that lets you get at properties of an object, and will just return null if it does not exist.

the problem with the first way is that your code becomes littered with null tests and every function becomes longer.

the problem with the second way is that what you may consider an error just becomes a silent action of setting something to null.

is one of these styles better? i am thinking null swallowing calls and not causing an error is better, because it is more terse and more often does what you want

null swallowing calls are probably good if you want to reduce development time and simple mistakes, but they will incur a bit of overhead internally, as it must always check to see if the argument is null first, and then return the default value if that is the case. There are times where the null value will never occur, and this check would be redundant, so if you are going for making the fastest implementation possible you would want to avoid anything that would check to see if the pointer was null in those cases. I've found that doing an assert(pointer != NULL) is good in most cases. Most of the routines I use are made to never return null pointers, and the ones that do return null pointers usually communicate some information via the null pointer, like the element in the dictionary was not found, or the player has no weapon drawn, or the monster has no target to pursue. Most of these scenarios need some special case to handle them, so an explicit check to see if the pointer is null helps set up that code.

You could try more robust forms of error handling, but unfortunately few languages support them.

Bad idea. You want to know when you're trying to deref a null pointer as you generally don't pass them intentionally.

They both have their uses.

Not ignoring is good when you require the object be there at that point, since it'll segfault when you try to access one.

Ignoring is good when there is a meaning behind it, like a certain configuration value not being set (different from being set to the empty string).

Initialize everything as 0 then you don't have to worry about nulls except as errors.

The idea of having a null object is a bad idea unto itself, maybe the worst thing appened to programming languages since COBOL.
Null should be replaced by either nullable types, or Option/Maybe types.

If I really had to choose between those, since the safe access operators exist basically to emulate an Option type, I choose that.

In Objective-C, there's no null object that swallows calls, you're sending messages to a null object which is legal.

Null object calls swallows.

My girlfriend won't swallow.

Date a null object.

>>10
You should teach her with your example! As soon as you came, quickly kiss her and swallow yourself!

swallow my anus

Perl 6 has soft exceptions, which blow up when evaluated (default) or when returned. It's very handy for doing bulk operations (eg. via map or hyperop), some of which may fail. You can then take the successful results. This saves you from having to check in advance for operations which might fail.

>>10

Then make her swallow. As soon as you cum, hold her head there until you feel her gulp it down.