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 theWifiEncryptionType
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?
5
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 WifiEncryptionType
s are supported.
If the list of supported WifiEncryptionType
s 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
).
3