私が読んだ初級プログラミングの本で取り上げていない単純なベストプラクティスの質問...何かしてもデータを返さないメソッドはすべて成功コードを返しますか？
機能またはメソッドがアクションを実行しても実際のデータを返さない場合、関数常にブール値の成功値を返す必要がある場合は、クラスプロパティまたはデータベース値をインクリメントします。私の
パートは「当たり前、もちろん」と言い、その後、私の部分は私のコードは、どんな小さな動作にブール値の成功を確認してすぐにオーバーフローだろうと言います。
現在、私は重要な機能上の成功を確認し、ではなく、最初の成功は、以下のものの有効なデータ/成功を保証することを前提に、重要なチェックが渡された場合に実行する機能をカスケード接続に。
しかし、私はただの愛好家です。プロは何をしていますか？
が成功しない場合は、が失敗すると予想します。戻り値をチェックしたり、間違った方法でチェックするのを忘れることができます。エラーごとに異なる値を使い始めると、すぐに手が届きません。 （-1：成功か失敗か？それは作家によって異なります）
代わりに、例外的な状況で例外を使用する必要があります。例外が処理されないと、通常、アプリケーションの終了が発生します。アプリケーションのチェックを忘れないようにしてください。彼らの構文ははっきりしており、あなたは小切手であなたのコードを捨てることはありません。
あなたは、言語を指定したので、ここで数を分割VB.NETの例ですされていない。
Function FloorDivide(ByVal a As Integer, ByVal b As Integer) As Integer
Dim result As Boolean = a/b
If Double.IsNaN(result) Then Throw New DivideByZeroException()
Return CInt(Math.Floor(result))
End Function
あなたは成功値をチェックせずに、それを使用することができますが、あなたはまだTry...Catch文を使用してエラーを処理することができます：
Try
FloorDivide(1, 0)
Catch ex As DivideByZeroException
MessageBox.Show("Something went terribly wrong! :D")
'Exit, maybe?
End Try
（！私はあなたがこの方法でゼロ除算を防ぐ必要があると言っていないことを、あなたの入力をフィルタリングする）
あなたはメートルに忘れない場合あなたのコードが静かに失敗するのではなく、すぐにテスト段階で思い出されます。また、はるかにクリーンで、Try...Catchの範囲は、おそらく特定のエラーを起こしやすい方法で発生したエラーを処理し、それらを放棄することができます。知るか？
一般に、例外を使用してください。あなたがそれらを扱うことを計画していると分かっているのであれば、検証を行う必要があります。
もちろん、すべての言語で例外がサポートされているわけではありません。その場合、成功コードを返すのはあなたの唯一の選択肢です。はい、あなたはいつも戻り値をチェックすることを忘れることができますが、それはAPIのユーザーの側ではちょうど悪い/ちょっとしたプログラミングです。戻り値が何を示しているかを知ることは決して実際上の問題ではありません。ドキュメンテーションにはすべての情報が含まれています。 –
@CodyGray：私は強く同意します。 – Ryan
本当にあなたがフォローしている言語とパラダイムに依存します。失敗して例外を処理した場合に値を返さないメソッドを持つ傾向があり、成功した場合は何も返しません（voidの意味で）。これは、すべてではないにしても、私が扱っている言語のほとんどが例外処理をサポートしているという事実によって強く影響されます。例外処理をサポートしていない言語では、成功のために定義された値を持つ数値を返すことになり、さまざまな種類の失敗に対してさまざまな値を返す緯度を持たせることができます。
あなたの質問に答えるには...おそらくそうではありません。すべてのメソッドでそれを行うのは、最初はあまりにも多くのオーバーヘッドであり、ブールの成功/失敗が行われる必要がある場所にとってはおそらく最良の答えではありません。
正直に言えば、正しいやり方があります。私はこれをやり遂げるために必要なことがあります。何度も私は両方の状況で自分自身を見つける。
私が感じる違いは、アプリケーションを見て弱いリンクの可能性がどこにあるのかよく分かります。それらはエラーチェックとブール値が返されたものです。そのような状況では、単純なtryキャッチは、関数が正常に動作していないか、安全に終了しているか、リダイレクトかクラッシュかを調べる非常に良い方法です。アプリ。
本当に、クラス分けとすべてのブール値の返信を本当に信じているハードコーダーがいると確信していますが、実際は正しいです...しかし、クライアントのサーバー構成、既存のアプリのコーディングプラットフォームなど
難しい状況に対処し、1週間以内に作成または修正されたアプリを必要とするクライアントから呼び出されるのは20年以上です。
"ベストプラクティス"に関する多くの質問と同様に、意見はこれによって異なります。
しかし、またはのいずれかの値を返すようにしなければならないという一般的な原則がCommand-query separationとなっています。
すべてからブール値の成功/失敗を返すのではなく、失敗のために例外を使用し、何かを行う目的があるメソッドから何も返さないことを好みます。
非常に依存しています。例外をサポートする言語では、多くの人々がエラーコードを返すことを好んでいます。なぜなら、それらの関数の呼び出し元を戻り値をチェックする必要がないという退屈さから解放するからです（そして、現実からほとんどのプログラマは怠け者であり、それをやりません）。例外をサポートしていない他の言語/環境、または例外をスローするコストが非常に高い状況では、エラーコードを返すことを選ぶかもしれません。しかし、いつものように、最も重要なのは**一貫性**です。スタイルを選んでそれに固執する。 –