Javaスタイルのスローを使用する方法C#でキーワードは?
-
27-09-2019 - |
質問
Javaで、 throws
キーワードを使用すると、メソッドが独自の例外を処理するのではなく、呼び出し方法にスローすることを宣言できます。
C#に同様のキーワード/属性はありますか?
同等のものがない場合、どのようにして同じ(または同様の)効果を達成できますか?
解決
Javaでは、例外を処理するか、メソッドを使用してスローする可能性のある方法としてマークする必要があります。 throws
キーワード。
C#は、C#のように、このキーワードや同等のものを持っていません。例外を処理しないと、キャッチされたり、捕まっていない場合はプログラムを終了するまで泡立ちます。
それを処理したい場合は、再スローを再スローすることができます。
try
{
// code that throws an exception
}
catch(ArgumentNullException ex)
{
// code that handles the exception
throw;
}
他のヒント
OPはについて尋ねています Javaに相当するC# throws
句 - ではありません throw
キーワード。これは、Javaのメソッドシグネチャで使用され、チェックされた例外をスローできることを示します。
C#では、Javaチェックされた例外に直接相当するものはありません。 C#には、同等のメソッド署名句がありません。
// Java - need to have throws clause if IOException not handled
public void readFile() throws java.io.IOException {
...not explicitly handling java.io.IOException...
}
に翻訳します
// C# - no equivalent of throws clause exceptions are unchecked
public void ReadFile()
{
...not explicitly handling System.IO.IOException...
}
はい、これは古いスレッドですが、回答をグーグルで検索しているときに古いスレッドを頻繁に見つけるので、見つけた便利なものを追加すると思いました。
Visual Studio 2012を使用している場合、IDEレベルを使用するために使用できるビルトインツールがあります。
使用する場合 XMLドキュメントコメント, 、上記のように、あなたは u003Cexception> タグメソッドまたはクラスによってスローされる例外のタイプと、いつまたはなぜスローされるのかについての情報を指定するタグ。
例:
/// <summary>This method throws an exception.</summary>
/// <param name="myPath">A path to a directory that will be zipped.</param>
/// <exception cref="IOException">This exception is thrown if the archive already exists</exception>
public void FooThrowsAnException (string myPath)
{
// This will throw an IO exception
ZipFile.CreateFromDirectory(myPath);
}
これが私が資金を提供しただけの同様の質問への答えです bytes.com:
短い答えはいいえです。C#にはチェックされた例外はありません。言語のデザイナーは、このインタビューでこの決定について議論します。
http://www.artima.com/intv/handcuffs.html
あなたが得ることができる最も近いことは、XMLドキュメントでタグを使用し、他の人が投げる例外を確認できるように、コード/アセンブリでNDOC生成ドキュメントを配布することです(これはMSDNドキュメントでMSが行うことです)。 Javaで慣れているように、未処理の例外について話すためにコンパイラに頼ることはできません。
ここでほとんどの答えを経験した後、私はいくつかの考えを追加したいと思います。
XMLドキュメントのコメントに依存し、他の人が依存することを期待するのは貧弱な選択です。私が出会ったほとんどのC#コードは、XMLドキュメントのコメントと完全かつ一貫してメソッドを文書化するものではありません。そして、C#で確認された例外がなくても、APIユーザーの目的のためにメソッドをすべて個別に処理する方法を知るためにスローするすべての例外をどのように文書化できるかという大きな問題があります。覚えておいてください、あなたはあなたがあなたの実装のスローキーワードであなた自身を投げるものについてのみ知っています。メソッドの実装内で使用しているAPIは、文書化されておらず、実装でそれらを処理していないため、知らない例外をスローする可能性があるため、あなたの発信者に直面して爆発します方法。言い換えれば、これらのXMLドキュメントのコメントは、チェックされた例外の代替品ではありません。
Andreasは、C#設計チームがチェックされた例外に反対した理由について、ここでの回答でAnders Hejlsbergとのインタビューをリンクしました。元の質問に対する究極の回答は、そのインタビューに隠されています。
プログラマーは、最終的にどこでも最終的に試してみるとコードを保護するため、例外が発生した場合は正しくバックアウトしますが、実際には例外の処理には関心がありません。
言い換えれば、特定のAPIにどのような例外が期待できるかについて誰も興味を持つべきではありません。また、特定の例外を本当に気にかけたい場合は、それらを処理する方法はあなた次第であり、Javaがキーワードをスローするようなメソッドシグネチャーを定義する人ではなく、APIユーザーに特定の例外処理を強制します。
--
個人的に、私はここで引き裂かれています。私は、例外をチェックしたことで、新しい異なる問題を追加せずに問題を解決しないことに同意します。 XMLドキュメントのコメントと同様に、最終的にブロックするすべてのものがすべて巻かれたC#コードを見ることはめったにありません。これは確かにあなたの唯一の選択肢であり、良い練習のように思えるものですが、私には感じます。
実際には、C#で例外をチェックしていないことは、良いことまたは悪いことと見なすことができます。
チェックされた例外が次の問題を提供するので、私自身はそれが良い解決策だと考えています。
- 低レベルで適切に処理できないため、ビジネス/ドメインレイヤーに漏れている技術的な例外。
- それらは、APIデザインで常にうまく機能するとは限らないメソッドシグネチャーに属します。
そのため、ほとんどの大規模なアプリケーションでは、チェックされた例外が発生したときに次のパターンが頻繁に表示されます。
try {
// Some Code
} catch(SomeException ex){
throw new RuntimeException(ex);
}
これは、基本的に、C#/。Netがすべての例外を処理する方法をエミュレートすることを意味します。
あなたはこれについて尋ねています:
例外を再投与します
public void Method()
{
try
{
int x = 0;
int sum = 100/x;
}
catch(DivideByZeroException e)
{
throw;
}
}
また
static void Main()
{
string s = null;
if (s == null)
{
throw new ArgumentNullException();
}
Console.Write("The string s is null"); // not executed
}
.NET CodeContractの間には、いくつかのつかの間の類似点があります EnsuresOnThrow<>
そしてジャワ throws
記述子は、2つの間には大きな違いがありますが、関数または方法から引き上げることができる例外のタイプとして、両方とも発信者に信号を送ることができます。
EnsuresOnThrow<>
どの例外をスローできるかを述べるだけでなく、それらがスローされることが保証されている条件を規定するだけでなく、例外条件が識別するのが些細なものでない場合、これは呼び出された方法で非常に面倒なコードになる可能性があります。ジャワthrows
どの例外をスローできるかを示すことを提供します(つまり、.NETの焦点はメソッド内にあり、それが契約して証明するために契約しますthrow
, 、一方、Javaでは、焦点が発信者に移行して例外の可能性を認めます)。- .NET CCは区別しません チェックされていないチェックされていません Javaが持っている例外、CCマニュアルセクション2.2.2は
「発信者がAPIの一部として予想すべき例外のためにのみ、例外的な条件を使用してください」
- .NETでは、発信者は例外を使用して何かをするかどうかを判断できます(例:契約を無効にすることにより)。発信者のJavaで 何かをしなければなりません, 、たとえそれが追加されたとしても
throws
インターフェイス上の同じ例外の場合。