Утверждения в ABAP

Question

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

Однако ничто из этого не подтверждается при написании кода ABAP для SAP. Я просто потратил большую часть часа, пытаясь отследить точное место, где утвердительная сторона давала мне непонятную ошибку. Это оказалось пять уровней в стандартном SAP-коде, который, по-видимому, пронизан операциями ASSERT. Теперь я знаю, что определенная переменная, идентифицирующая таблицу IS NOT INITIAL, в то время как ее сопровождающая переменная идентифицирует поле.

Это ничего мне не говорит. Компонент Web Dynpro, запускающий этот код, на самом деле «ловит» это утверждение, показывая мне общее сообщение об ошибке, которое служит только для предотвращения запуска отладчика при отключении assert.

Таким образом, мой вопрос заключается в том, какие рекомендации или рекомендации используются для использования утверждений в ABAP. Является ли этот SAP плохой код? Является ли принятой практикой заполнять ваш пользовательский код утверждениями и оставлять их при отправке кода? Если да, то как мы будем обращаться с этими утверждениями во время выполнения, чтобы приложение не разбилось и не сработало, все еще имея возможность определить причину ошибки?

Answer 1

Рекомендации и практические рекомендации практически одинаковы при разработке ABAP, как на любом другом языке. Утверждение должно использоваться только как внутренние проверки руководства, исключения для регулярных ошибок проверки ввода и другие вещи. Возможно, было бы разумно оставить утверждения в коде. В конце концов, скорее всего, вы, скорее всего, захотите, чтобы ваша программа рухнула контролируемым образом, а затем продолжила непредвиденным образом и, возможно, повредила некоторые важные данные в процессе, не заметив никого. Взгляните на checkpoint groups, если вы не хотите, чтобы ваша программа прерывалась в производственной среде, но, на мой взгляд: какая польза от проверки здравомыслия (как последняя линия защиты), если она отключена в среде, где она больше всего важна ?

Конечно, я предполагаю, что вход подтвержден правильно (чтобы предотвратить сбои) и что все API-интерфейсы используются в соответствии с предполагаемым использованием и документацией. К сожалению - как и для любого другого языка программирования - разработчик должен соответствовать этим стандартам.