Java の "throws" 句 (メソッド宣言内) が C# に含まれていないのはなぜですか?
5 に答える
Anders Hejlsberg (リード C# アーキテクト) は、このインタビューで次のように説明しています。
(Patrikのやや決定的な答えに加えて。)
Java のチェック例外は、非常に物議を醸す問題です。私はそれらが大好きで、C# を書いているときにそれらが恋しくなりました。シートベルトなしで運転しているような感覚でした。今、彼らは私を悩ませています...理論的には良いアイデアのように聞こえますが、確かに多くの悲しみをもたらしましたが、具体的な利益はあまりありませんでした. 例外をチェックすることで救われたであろう C# コードのバグに遭遇したことを思い出せません。それが起こらないと言っているわけではありませんが、私には起こっていません。
厄介なことに、C# はまだ緩すぎるように感じられますが、Java のアプローチはまったく適切ではありません。発見されるのを待っているより良い解決策があるようです.Javaの試みは良い実験でしたが、うまくいきませんでした.
言語機能としてのチェック例外は、Microsoft と Sun の間の文化的な違いの一部を明らかにしていると思います。
ほとんどの場合、Microsoft はクライアント企業です。彼らが作成するソフトウェアのほとんどと、彼らの開発スタックが対象としているものは、クライアント ソフトウェアです。
はい、はい、Microsoft がサーバー ソフトウェアを作成していることは知っています。ただし、Office と Windows は、収益の点で Windows Server と Exchange よりもはるかに大きくなっています。
.NET で記述されたほとんどのソフトウェア (VB 6 ではなおさら) はクライアント ソフトウェアであると言っても過言ではありません。確かに、その大部分は Web サーバー上で実行される Web ソフトウェアですが、そのほとんどは実際には ... 「クライアント タイプの Web アプリ」です。ほとんどの Web アプリは "Word" に似ていて、Exchange に似ていると思います。
はい、WCF や SOAP サービスなどがあることは知っていますが、それらは通常、「クライアント」タイプのものの「ミドルウェア」にすぎません。
一方、Sun は主にサーバー会社です。彼らのソフトウェアは、ユーザー インターフェイスに関しては、必ずしも最高とは言えません (これは、Unix ではわずかではありません... Solaris だけです.. Mac OS X は unix ベースであり、驚異的なユーザー インターフェイスを備えています。2 つの違いつまり、Sun は Apple ほど UI に関心がありません)。彼らは、すべてをサーバーにプッシュしようとする THIN CLIENTS も販売しています。
つまり...いずれにせよ...Microsoftは主にクライアント企業であり、Sunは主にサーバー企業です。
サーバー ソフトウェアを作成する場合、信頼性は非常に重要です。それは巨大です。メール サーバーがクラッシュすると、人々はメールを受信できなくなり、ビジネスは停止します。そのため、サーバーが発生する可能性のあるほとんどのエラーをインテリジェントに処理できるようにすることは、電子メール サーバーを販売する上で重要な部分です。
クライアントソフトウェア付き。信頼性は重要ですが、サーバー ソフトウェアほど重要ではありません。ほとんどの主要なシナリオが機能している限り、人々は満足しています。多くの場合、クレイジー エッジ シナリオは無視するか、一般的に処理することができます。
信頼性を高めるための鍵の 1 つは、発生する可能性のあるすべてのエッジ ケースを確実に処理することです。別のプロセスによってロックされているためにデータベース ファイルを開くことができない場合、または読み取る権限がない場合はどうなりますか? メモリやディスク容量が不足したらどうしますか? この手順の実行中に電源が切れるとどうなりますか?
非常に高い信頼性要件があるため、チェック例外があると役立ちます。予期していなかったシナリオがあり、すべてを予測することがビジネスにとって重要な場合は、コンパイラに「RocketFuelExhaustedException を処理していない」と伝えてもらうと役に立ちます。
したがって、チェック例外は、サーバー ベンダーとしての Sun の観点から生じていると思います。
クライアント ソフトウェア開発者に開発者ツールを販売するクライアント企業である Microsoft にとって、チェックされた例外はもちろん、実際の作業の邪魔になるだけのひどく苛立たしいものです。
とにかく、それは私の$ 0.02です...
主な理由は、C# の設計者が「チェック済み例外」を使用しないことにしたためです。これは、開発者が try-catch ブロック内で例外をスローする句を囲む必要がないことを意味します。これは小規模なアプリケーションにのみ役立つものであり、大規模なプロジェクトには実際の利点はないと考えられていました. さらに、チェックされた例外は、常に空の catch ブロックを使用する開発者によって実際に悪用されていました。チェックされた例外がないため、どの例外がスローされる可能性があるかをメソッドで宣言する必要はありません。
「チェック済み例外」を使用するかどうかは議論の余地のあるトピックですが、ほとんどの人はその必要がないことに同意しているようです。Java の主要なフレームワークである Spring は、チェック済み例外を実行時例外に変換します。
例外は明らかに「例外的な」イベントです。.net のパラダイムでは、例外が発生することはありません (そのため、 などのメソッドがTryParse
あります)。