Safe разыменования указателя в

Question

C++ В нашей базе кода у нас есть много конструкций, как это:

auto* pObj = getObjectThatMayVeryRarelyBeNull(); 
if (!pObj) throw std::runtime_error("Ooops!"); 
// Use pObj->(...) 

В 99,99% случаев эта проверка не срабатывает. Я думаю о следующем решении:

auto& obj = deref_or_throw(getObjectThatMayVeryRarelyBeNull()); 
// Use obj.(...) 

Где deref_or_throw объявлен следующим образом:

template<class T> T& deref_or_throw(T* p) { 
    if (p == nullptr) { throw std::invalid_argument("Argument is null!"); } 
    return *p; 
} 

Этот код гораздо понятнее и работает как мне нужно.

Вопрос: я изобретаю колесо? Есть ли какое-то смежное решение в стандартном или импульсном режиме? Или у вас есть некоторые комментарии к решению?

PS. Связанный с этим вопрос (без ответа): Is there a C++ equivalent of a NullPointerException

Answer 1

Существует два способа решения проблемы «редкого случая с нулевым указателем». Во-первых, это предлагаемое исключение. Для этого метод deref_or_throw - хорошая вещь, хотя я бы предпочел выбросить runtime_error, а не исключение invalid_argument. Вы также можете подумать о том, чтобы назвать его NullPointerException, если хотите.

Однако, если случай ptr != nullptr на самом деле является предварительным условием для алгоритма, вы должны стараться изо всех сил добиться 100% -ной безопасности при наличии этого не нулевого случая. В этом случае подходящей является assert.

assert Преимущества:

• Нет затрат во время выполнения в режиме выпуска
• делает кристально ясным для разработчика, что он несет ответственность за это никогда не произойдет.

Недостатки assert:

• Потенциальный неопределенное поведение в режиме выпуска

Вы должны также рассмотреть вопрос о написании метода getObjectThatMayNeverBeNullButDoingTheSameAsGetObjectThatMayVeryRarelyBeNull(): метод, который гарантированно возвращает ненулевой указатель объект, который в остальном полностью эквивалентен вашему первоначальному методу. Однако, если вы можете пройти лишнюю милю, я бы настоятельно рекомендовал не возвращать необработанный указатель. Embrace C++ 11 и вернуть объекты по значению :-)

Answer 2

Вы можете и, вероятно, должны проектировать с учетом null. Например, в вашей проблемной области, когда имеет смысл для методов класса возвращать null? Когда имеет смысл вызывать функции с аргументами null?

В общем, полезно, если возможно, удалять null ссылки из кода. Другими словами, вы можете запрограммировать на инвариант, что «здесь здесь не будет нуля ... или там». Это имеет много преимуществ. Вам не придется обфускать код, обертывая методы в deref_or_throw. Вы можете получить больше семантического значения из кода, потому что, как часто вещи null в реальном мире? Ваш код может быть более читаемым, если вы используете исключения для указания ошибок, а не null. И, наконец, вы уменьшаете необходимость в проверке ошибок, а также уменьшаете риск ошибок времени выполнения (разыгрывание ужасных нулевых указателей).

Если ваша система не была разработана с null случаев в виду, я бы сказал, что лучше оставить его в покое и не сходят с ума оборачивать все с deref_or_throw. Возможно, возьмите подход Agile. Когда вы кодируете, проверьте контракты, которые предлагают объекты класса в качестве сервисов. Как часто можно ожидать, что эти контракты будут возвращены null? Что такое семантическое значение null в этих случаях?

Возможно, вы могли бы идентифицировать классы в своей системе, от которых можно было бы ожидать разумного возврата null. Для этих классов null может быть действительной бизнес-логикой, а не бахромой, которая указывает на ошибки реализации. Для классов, которые, как ожидается, будут возвращены null, дополнительная проверка может стоить безопасности. В этом смысле проверка на null больше похожа на бизнес-логику, а не на детали реализации низкого уровня. Однако, несмотря на то, что систематическое обертывание всех указаний в deref_or_throw может быть излечением, которое является его собственным ядом.