問題
以下のブロックコードがあるとします。SOQLクエリの後、retrieveRecordsリストが空の場合、コードの実行が中断されるようにするために、開発者は何をする必要がありますか。
try {
List <Accounts> retrieveRecords = [SELECT Id FROM Account WHERE Website = null];
} catch(Exception e){
//例外ロジック
}
- retrieveRecords変数の状態をチェックし、変数が空の場合はカスタム例外をスローする。
- retrieveRecords変数の状態をチェックし、変数が空の場合はSystem.assert(false)を使用する。
- retrieveRecords変数の状態をチェックし、変数が空の場合はリストの最初の要素にアクセスする。
- retrieveRecords変数の宣言を、リストのAccountから単一のAccountに置き換える。
正解
- retrieveRecords変数の状態をチェックし、変数が空の場合はカスタム例外をスローする。
- retrieveRecords変数の状態をチェックし、変数が空の場合はSystem.assert(false)を使用する。
- retrieveRecords変数の状態をチェックし、変数が空の場合はリストの最初の要素にアクセスする。
- retrieveRecords変数の宣言を、リストのAccountから単一のAccountに置き換える。
解説
通常の開発プラクティスでは、例外処理を適切に実装し、予期しないエラーや例外を適切にハンドルすることが求められます。この問題は、特定のシナリオや条件下でコードの実行を中断させる方法に焦点を当てていますが、実際の開発環境でのベストプラクティスを反映しているわけではありません。
このような背景から、この問題は「ひっかけ問題」として捉えることができます。日常の開発作業において、このようなコードを書くことは推奨されない点を理解しておくことが重要です。
それぞれの選択肢の理由について説明します。
□ retrieveRecords変数の状態をチェックし、変数が空の場合はカスタム例外をスローする。
これは不正解です。カスタム例外をスローすると、catch(Exception e)ブロックでキャッチされ、コードの実行が中断されません。しかし、通常の開発プラクティスでは、このような方法で例外を適切にハンドルし、エラー情報を明確にするためにカスタム例外を使用することが推奨されます。
□ retrieveRecords変数の状態をチェックし、変数が空の場合はSystem.assert(false)を使用する。
これは正解です。System.assert(false)は、条件がfalseの場合にエラーをスローし、コードの実行を中断します。ただし、通常の開発ではアサーションはテストクラス内でのみ使用され、途中で処理を中断する目的で使われることはありません。
□ retrieveRecords変数の状態をチェックし、変数が空の場合はリストの最初の要素にアクセスする。
これは不正解です。リストが空の場合、最初の要素にアクセスしようとするとNullPointerExceptionがスローされますが、catch(Exception e)ブロックでキャッチされ、コードの実行は中断されません。通常の開発プラクティスでは、リストにアクセスする前にそのリストが空でないことを確認することが推奨されます。
□ retrieveRecords変数の宣言を、リストのAccountから単一のAccountに置き換える。
これは不正解です。変数の宣言を単一のAccountに変更しても、コードの実行が中断されるわけではありません。通常の開発プラクティスでは、変数の目的や使用方法に応じて適切なデータ型を選択し、変数を宣言することが重要です。リストを期待している場面で単一のオブジェクトを使用すると、予期しないエラーや問題が発生する可能性があります。
コメント