Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Objective C has a concept of a nil object which would accept any method call with any parameters without complaining and silently return another nil.

I have used something similar in Java using easymock and mockito for testing. Is there something similar for main line code? Is it even a good idea to have something like this?

One use-case where I am considering using it is with optional metrics. We have codahale metrics counters on which we call mark() every time an event is generated. This is surrounded by an If/then to check for metrics enabled flag. I could just use a nil object as counter and silently accept the mark call if metrics are not enabled.

share|improve this question
    
how do you handle methods with primitive result type? (eg. equals and hashCode) –  user470365 Nov 14 '12 at 8:28
    
Bear in mind that nil is not an object -- it's a pointer that doesn't point to anything. The language happens to be defined such that it's (often) legal to send messages to nil, but nil doesn't represent an object. (Of course, there's also [NSNull null], which is an object.) –  Caleb Nov 14 '12 at 15:31
    
@user470365: In such cases, the equivalent of "0" for that primitive type is returned (i.e., "NO", "0", "0.0", etc.). –  mipadi Nov 14 '12 at 21:57
    
@Caleb it's always, not often, legal to message nil. Some other objects don't like having nil as a message parameter. –  user4051 Nov 15 '12 at 6:43
    
@GrahamLee Perhaps I was being too careful. Sending a message to nil is always legal, using the returned value may not be, so while legal it may nevertheless be an error. As you point out, some methods may not like nil as a parameter. E.g. [[NSString alloc] initWithString:[foo name]] will throw an exception if foo is nil because [foo name] will return nil. Sending -name to foo is legal, but that's not much comfort to the user who wonders why your app just crashed. –  Caleb Nov 15 '12 at 8:32
add comment

2 Answers

up vote 2 down vote accepted

Java doesn't have this built in - it's a programmer error to call a message on null which causes a runtime exception. However, there is a pattern called the Null Object Pattern, which programmers use to provide their own equivalent.

Imagine that you have some interface, representing a connection to a database. You might define the interface like this:

public interface DatabaseConnection {
public void connect(String username, String password, URL databaseLocation);
public void disconnect();
public String executeQuery(String query);
}

Your Null Object might look like this:

public class NullDatabaseConnection implements DatabaseConnection {
public void connect(String username, String password, URL databaseLocation) {}
public void disconnect() {}
public String executeQuery(String query) { return ""; }
}

The disadvantage of doing this compared with the ObjC approach is that you have to write the above code - you can't automatically get the behaviour by using the nil object. The advantage is that this explicit Null object works as you'd expect in all cases: you can put it into a collection for example, something you can't do with Objective-C's nil.

share|improve this answer
    
Hmm this will work, I can probably create a utility class which takes an interface and returns an implementation which mocks out all the methods according some basic rules, nulls for objects default values for primitives. I mostly want to use it for void methods anyway. –  Usman Ismail Nov 14 '12 at 14:58
add comment

This is a fundamental part of the Objective-C runtime. On every single method call, the first thing it does is check if the object reference is nil, and immediately returns if so. The Java runtime surely does a similar check, but responds by throwing a NullPointerException. So you're asking how to change the fundamental behaviour of the runtime.

There are a couple of ways to achieve a similar effect in Java:

  • Create a dummy implementation of your metrics interface that does nothing. Assign this to your metrics object variable.
  • or: Create a single, static entry point to your metrics class, and pass in the instance as the first argument, and check if it's null before doing anything else. e.g.

.

public static void doMetrics(Metrics m, otherArgs ...) {
    if (m == null) return;

    ... do stuff with m ...
}

Both of these come at the minor performance cost of a pointless method call when metrics are switched off.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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