自定义转换运算符中的null值处理方案探讨

异常类型选择 #

针对macAddress为null的情况，应显式抛出ArgumentNullException(nameof(macAddress))，原因如下：

• 放任框架抛出NullReferenceException不可取：NRE的语义是“意外的空引用访问”，无法明确传达“转换参数为null导致失败”的意图，调用者难以快速定位问题。
• InvalidCastException语义不符：该异常用于表示“类型本身不支持转换”，但非null的MacAddress是可以正常转换的，只是参数无效，因此不适用。
• ArgumentNullException是正确选择：它明确表示“传入的参数为null，而该参数不允许为null”，完全匹配当前场景的语义，能清晰告知调用者问题根源。

运算符类型选择：explicit而非implicit #

根据.NET设计指南，隐式转换必须是无异常、无信息丢失的安全转换。由于当前转换在参数为null时会抛出异常，不符合隐式转换的要求，因此必须将运算符设为explicit：

• 显式转换要求调用者主动使用(BluetoothAddress)macAddress语法，明确知晓转换存在失败风险，符合“显式转换用于可能有风险的场景”的设计原则。
• 避免调用者在无意识的隐式转换中触发异常，提升代码的可读性和安全性。

优化后的实现代码 #

public static explicit operator BluetoothAddress(MacAddress macAddress)
{
    if (macAddress is null)
        throw new ArgumentNullException(nameof(macAddress));
    
    var bytes = macAddress.ToByteArray();
    ulong Shift(int i) => ((ulong)bytes[i]) << ((5 - i) * 8);
    ulong value = Shift(0) | Shift(1) | Shift(2) | Shift(3) | Shift(4) | Shift(5);
    return new BluetoothAddress(value);
}

内容的提问来源于stack exchange，提问作者LWChris