Null Object Pattern and Input validation - copy real implementation or silently accept everything?

Question

I have a WifiComponent in my Camera in my client application. It's responsible for handling the Wifi-related functionality of the Camera. The Camera represents a real world camera.

This WifiComponent can either be enabled (in which case I can do things with it, like checking connection status and scanning) or disabled (in which case you can't do anything with it at all, other than asking whether it's enabled).

When creating a Camera in my client application, I ask the camera whether its WifiComponent is enabled. Then I construct the appropriate subclass of WifiComponent, either WifiComponentImpl or NullWifiComponent.

Implementing the supportedWifiTypes() and wifiScan() methods are easy. The NullWifiComponent doesn't support any types, is instantly done with scanning and finds no results.

But now I have to implement a bool connect(WifiNetwork network, String password) method. I want to say that I failed to connect... But I don't even support the WifiEncryptionType provided in the WifiNetwork! The real implementation throws an IllegalArgumentException if you pass it an unsupported WifiEncryptionType wifi network.

Do I...

• Throw IllegalArgumentException, because I don't support the WifiEncryptionType requested?
• Silently fail to connect (return false), no matter what's provided?

Generalized question:

If the real implementation fulfills a contract, and part of this contract is to throw exceptions for certain inputs, should a null-implementation prioritize its neutrality or the contract?

Answer 1

As the null-implementation is supposed to be a drop-in replacement for the full-functional implementation, the null-implementation should fully adhere to the interface that it implements.

If the WifiComponent interface specifies that connect() throws an exception if it gets invoked with an unsupported WifiEncryptionType, then that is exactly what your null-implementation should do, especially if the application must use the same WifiComponent interface to learn which WifiEncryptionTypes are supported.

If the list of supported WifiEncryptionTypes doesn't come from your null-implementation, then your null-implementation should only throw an exception if a functional implementation is also required to throw it.

If the WifiComponent interface doesn't specify that an exception must be thrown, then it is better to assume the value would be acceptable to a functional implementation and report a generic connection failure (return false).