Returning Unmodifiable Collections only tees you up for runtime exceptions?

Question

Seeing as how there are no distinct Unmodifiable Collections interfaces, aren't you just setting yourself up for runtime exceptions by returning Unmodifiable Collections from method invocations? example:

public class Start {    
    public static void main(String[] args) {
        try {
            List<String> listA = getListA();
            listA.add("whatever");
            System.out.println("listA: " + listA.get(0));

            List<String> listB = getListB();
            listB.add("whatever");
        } catch(Exception e) {
            System.out.println("SURPRISE!!! you should have known that listB was unmodifible.");
        }
    }

    static List<String> getListA() {
        return new ArrayList();
    }

    static List<String> getListB() {
        return Collections.unmodifiableList(new ArrayList());
    }
}

At best, in javadoc I could write in bold letters "the returned Collection is Unmodifiable!"?
In what scenario is returning Unmodifiable Collections worth the risk of runtime exceptions?

can't you return an `Iterable` or whatever the java equivalent of the `IEnumerable` interface in C# is called? — sara, Apr 05 '16 at 20:00

Stephen C · Accepted Answer · 2016-03-13T03:37:56.737

6

Returning Unmodifiable Collections only tees you up for runtime exceptions?

Yes and no.

Yes, it does do that.
No, it doesn't only do that. It also prevents a class of problems from occurring; i.e. problems where some code has actually modified a collection that it wasn't supposed to.

So what are the alternatives in Java?

Instead of returning an unmodifiable wrapper for a collection, you could return a copy of the original collection. Problems:
1. Copying a large collection is expensive.
2. The caller might end up unwittingly modifying the copy when it "needs" to modify the original. In other words, diagnosing the root (conceptual) problem becomes harder.
Try to express modifiable versus unmodifiable via classes and interfaces. People have tried ... but it doesn't work.

In short, the Java approach of unmodifiable collections that throw an exception when you try to modify them is probably the best solution possible in the context of the current Java type system. The exceptions are actually a good thing ... because they make diagnosing the underlying problems easier.

At best, in javadoc I could write in bold letters "the returned Collection is Unmodifiable!"?

Yes. That is advisable. Though bold letters is probably inadvisable. (Too much shouting makes people deaf ...)

In what scenario is returning Unmodifiable Collections worth the risk of runtime exceptions?

I would consider doing it whenever the correct behavior of the API depends on the caller not modifying the returned collection. (You do also need to weigh up the impact on performance; e.g. the cost of creating the wrapper objects, and the extra cost for the wrapped method calls.)

edited Mar 13 '16 at 03:37

answered Mar 13 '16 at 03:27

Stephen C

25,180
6
64
87

1

I disagree with you on your assertion that "the Java approach of unmodifiable collections [...] is probably the best solution possible": The correct solution would have been the Objective-C approach: The modifiable class is a *subclass* of the non-modifiable one. This is correct, because the mutable subclass *adds* the ability to change instead of *removing* it as Java does. – cmaster - reinstate monica Mar 13 '16 at 07:09
Not sure "exceptions are actually a good thing" makes sense. I'd think that users would associate poor performance with their cpu, not my app. But a runtime exception is justifiably all on me. I am guessing that after the 3rd exception, the user uninstalls the app. – konishiki Mar 13 '16 at 13:35
1

1) When the purpose of an exception is to tell you there is a bug, performance is irrelevant. You fix the bug and the exception shouldn't be thrown again. 2) Hopefully, you fix the bug *before* you try to sell the code to someone. If not, then you *deserve* to have your customers complaining at you. – Stephen C Mar 13 '16 at 13:44
The Objective C approach is conceptually broken. It breaks Liskov's substitutability principle ... at the semantic level. If a modifiable collection is-a unmodifiable collection, then you should not be able to modify it. – Stephen C Mar 13 '16 at 13:46
Both should be a subclass of an interface, which exposes read-only methods but lacks the guarantee of immutably – Demi Aug 07 '16 at 02:10

score 6 · Answer 2 · answered Mar 13 '16 at 05:36

I don't know why people think of such exceptions as risky. Developer writes code using add. Developer thinks it might be a good idea to test the code he just wrote. Developer gets a big scary exception. Developer fixes code.

Much more risky is returning a mutable reference to a data structure which is still used internally to a class, perhaps to avoid an expensive defensive copy. Then that data structure is externally modified in a way the original class didn't anticipate, causing a subtle bug that isn't caught by testing, because it isn't directly related to the code that was just changed.

Of course, this is far from the ideal way to handle immutable collections. Decent implementations have add functions that return a new collection that shares as much as possible of the old collection without mutating it. However, as a quick wrapper to remove a certain set of errors, it's not the worst thing.

Returning Unmodifiable Collections only tees you up for runtime exceptions?

2 Answers2