回答。

KotlinはJavaと同様に例外処理を実装していますが、重要な違いがあります。Kotlinでは、try、catch、およびfinallyという構文が使われますが、基本的な違いはKotlinにはchecked exceptionが存在しないことです。つまり、すべての例外（実行時エラー）はuncheckedと見なされ、関数のシグネチャに明示的に指定したり、明示的に捕捉したりする必要がありません。

主なポイント：

try/catch/finallyブロックは例外を捕捉し処理するために使用されます。finallyブロックは、例外がスローされた場合でも常に実行されます。
Javaとの違い：Kotlinではすべての例外がuncheckedです。これにより構文が簡素化されますが、エラーハンドリングに対して注意深いアプローチが必要です。
Kotlinはtryブロックの「return value」をサポートしています。つまり、tryを式として使用し、結果を返すことができます。
新しいイディオム：フロー制御のためにtry/catchを使用しないことが推奨されます。本当に例外的な状況にのみ使用してください。

fun parseIntOrNull(str: String): Int? = try {
    str.toInt()
} catch (e: NumberFormatException) {
    null
}

ベストプラクティス：

ロジックの制御（フロー制御）には使用しないでください。
useを使用してリソース管理を行い、自動的に閉じる（例えばファイル）ことをお勧めします。
空のcatch文で例外を無視しないでください。

挑戦的な質問。

Kotlinでは、関数がスローする例外をシグネチャに指定する必要がありますか（Javaのようにthrowsを介して）？

正しい回答： いいえ、Kotlinにはchecked exceptionのメカニズムがありません。すべての例外はuncheckedです。関数のシグネチャにthrowsという構文は存在しません（例外はJavaとの互換性のための@Throws注釈であり、interopのみに使用されます）。

このテーマの微細な知識不足による実際のエラーの例。

物語

プロジェクトで、checked exception（例えば、IOException）を使用しているJavaコードを移行しました。Kotlinへの移行後、開発者はファイル操作時に例外を処理し忘れ、アプリケーションは実際のファイルでクラッシュし始めました。なぜなら、誰もIOエラーを処理せず、コンパイラがJavaのように警告してくれると思ったからです。

物語

チームのメンバーの一人が誤ってフロー制御のためにtry/catchを使用し、ログの解析を遅くしました（無効な各行に対してNumberFormatExceptionを捕まえていたため、大量のデータでパフォーマンスが急激に低下しました）。

物語

JVM用のプロジェクトでKotlinから呼び出されたJavaコードはchecked exception（throws）を宣言していました。Kotlinコードはすべてが「unchecked」だと考え、例外を処理しなかったため、重大なエラーが本番環境でのインシデントに至るまで気づかれませんでした。

Kotlinにおける例外処理はどのように機能しますか？ニュアンス、Javaとの違い、checked/unchecked例外の処理、'try'、'catch'、'finally'、伝播、およびベストプラクティスを説明してください。例を挙げてください。

回答。

主なポイント：

ベストプラクティス：

挑戦的な質問。

このテーマの微細な知識不足による実際のエラーの例。