正常処理、というより仕様が望まなかった場合に、機能が取る振る舞いのこと。
よく「業務的にないから」という理由で規定しない設計者もあるが、エラーメッセージもなく無言でスルーされては、再現も解決もままならない。
* SUBRCについて [#z3d54c6c]
-[[SELECT>ABAP/SELECT]]文でのSUBRC
現実的には、UP TO n ROWSを使用しない限りは「存在しない」ことを意味する4のみが返ってくるため、暗黙的に''<> 0''という使い方で判断されるのが一般的か。
なお、判定は[[サブルーチン>アドオン/サブルーチン]]の外で実施した方が、[[関数>アドオン/関数]]としての役割はつぶしがきく。
-[[汎用モジュール>SAPのオブジェクト/汎用モジュール]]呼び出し時のSUBRC
これについては、標準とAdd-Onのものでまた違ったりもするが、''「意図しない現象」として十把一絡げに<> 0''という使い方が為されることが多い。
現実的には、その顧客で或いは機能に依存した細やかな動きはフェーズが進むまで判明しないことも多く、まずは<> 0としておいて、統合テストなり運用テストなりで突き詰められたベースで深堀して行くのがトータルで良いかと思う。
-[[CATCH>ABAP/CATCH]]文でのSUBRC
これが意外に重要で、計算ロジック系で''ゼロで除算してしまって[[ショートダンプ>SAPの共通用語/ショートダンプ]]''なんてのは、相当にこっ恥ずかしい。
シニアならば当然のようにケアすることではあるが、ジュニアを自認するレベルならば「割り算ならいつも書く」としておいた方が無難かと思う。
* その他ビジネスロジックでの例外処理 [#lc574a6e]
システム上は健康なデータであっても、顧客要件であったり後続プロセスを担保するために処理を停止させたりエラーメッセージを表示して注意を促す場合などが該当する。
こういった場合については、汎用的な引数を設けて[[汎用モジュール>SAPのオブジェクト/汎用モジュール]]にしてしまうのがよいだろう。
~
~
CENTER:【スポンサードリンク】
#htmlinsert(amazon_book_sap_system_implement)
~
~
----
#pcomment(reply)
