Java から Kotlin へ

第19章. 投げて返す

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

Javaはチェック付き例外とチェックなし例外を使ってエラーを表現し、処理する。 Kotlinは例外をサポートしているが、同じようにチェック付き例外を言語に組み込んでいない。 なぜKotlinはJavaのアプローチを拒否したのか、そして代わりに何を使うべきなのか？

、物事がうまくいかないことを発見するのに長い間コンピューターをプログラミングする必要はない。

...いろいろな意味で。

あなたの著者は、そのキャリアの初期において、エラーに目をつぶる傾向があった。 少なくともプロジェクトの初期においては、今でもそうであることが多い。 しかし、システムが成長するにつれて、エラーがアプリケーションにどのような影響を与えるかを学び、最初は断片的に、後には経験に基づいた戦略をもって、対処するためのコードを追加し始める。 この点で、エラー処理は、ソフトウェア設計の他の側面と同じように進化していく。 類似システムの経験を生かして前もって設計することもあれば、ソフトウェアが何を必要としているかを書くことで教えてもらうこともある。

より意図的な戦略がない場合、ほとんどのシステムは、何か問題が発生したときに例外を発生させ、その例外をキャッチし、何らかの外部レベルでログに記録することをデフォルトとしている。 コマンドラインユーティリティは、この場合、ユーザが問題を修正して再試行するのに十分な情報を提供したことを期待して、そのまま終了する。 サーバアプリやイベントループを持つGUIは、通常、現在の対話のみを中止し、次の対話に移る。

多くの場合、これはユーザにとって不愉快な体験に過ぎないが、時にはエラーがシステムの永続的な状態を破壊してしまい、初期化した問題を修正して再試行してもうまくいかないことがある。 これが「電源を切って入れ直す」という賢明なアドバイスの源である。 我々のシステムは主に安全な状態で起動するため、再起動後に再試行が成功するはずである。 そうでない場合、おそらく唯一の解決策がオペレーティング・システムの再インストールという、破壊された永続的な状態を取り除く究極の方法しかない状況に陥っていることだろう。

インターネットの再起動

ダンカンは、ネスト・サーモスタットとIfThisThenThatの統合がうまくいかないという問題を抱えていた。 IFTTTはネストがホームモードに入ったときに通知を受け取っていたが、外出モードには入っていなかった。 2017年2月28日のAWSの大停電で、不思議なことに問題は解決した。 必要なのはインターネットの再起動だけだったことがわかった。

エラーの管理が不十分で、それにもかかわらずシステムが成功した場合、エラーによる破損の診断と修正が拡大し、チームのすべての時間を埋め尽くすことになりかねない。 これは、ソフトウェア・プロジェクトにとってあまり良い場所ではない。 私たちがなぜ知っているかは、私たちに尋ねてほしい！

エラーはユーザを困らせるし、修正できたとしても、修正に多大な労力を要する破損につながる可能性があるからだ。 どのようなエラーが見られるのか？

プログラミングがうまくいかない理由はさまざまだ。プログラムと言う場合は、関数、メソッド、プロシージャなど、私たちが呼び出すあらゆるコードを指す。 また、うまくいかないと言う場合は、私たちが期待した仕事ができないことを指す。 ...