回答。

Kotlinでは、例外処理はtry/catch/finally構文を用いて実装されていますが、Javaのアプローチとは異なり、未チェック例外に重点を置き、シンプルな構文が特徴です。重要な違いは、Kotlinにはチェック済み例外が存在しないため、プログラマはthrowsを明示的に指定したり、そのような例外を捕捉したりする必要がないことです。

問題の背景

Javaではチェック済み例外と未チェック例外が使用されており、チェック済み例外は明示的な捕捉または宣言を必要とします。これにより、冗長なボイラープレートコードが生じ、コードが使いづらくなることがよくあります。Kotlinはよりシンプルに設計されており、すべての例外は通常未チェック（RuntimeExceptionから継承されたもの）であり、処理が容易でコードがより読みやすくなります。

問題

Javaの開発者がKotlinでチェック済み例外を捕捉しようとすると、コードはコンパイルされますが、意味が失われてしまいます。また、finallyを無視して使用すると、リークや動作しないコードが生じる可能性があります。

解決策

Kotlinでは、try/catch/finallyを簡潔に使用するべきです：

fun process(data: String): Int = try {
    data.toInt()
} catch (e: NumberFormatException) {
    0
} finally {
    println("Processing done")
}

try/catch/finallyは式として機能することができ、関数の結果として返される値や変数に代入されます。
複数の例外を捕捉し、catch内でwhenスイッチを使用して異なる例外タイプに応じた反応を実装できます。

主な特徴：

チェック済み例外が存在しないため、宣言または明示的に処理する必要がありません。
try構文は式として機能（結果を返します）。
最終的な処理（リソースのクリーンアップなど）にはfinallyを使用できますが、戻り値を変更する操作は行わない方が良いでしょう。

トリックのある質問。

finallyブロックで例外がスローされた場合、何が起こりますか？それは戻り値にどのように影響しますか？

finallyからスローされた例外は、try/catchブロックからの他の例外やreturnを常に覆い隠すため、重要なクラッシュの原因に関するデータが失われる可能性があります。

fun demo(): Int = try { 1 } finally { throw RuntimeException("error in finally") }

Kotlinではtry/catchは式になることができますか？Javaとの違いは何ですか？

はい。Kotlinのtry/catch/finallyは式であるため、値を返し、値が許可される場所で使用できます。

val value = try { risky() } catch (e: Exception) { fallback() }

Javaではこれは単なるステートメントです。

throwsを持つ外部Java関数が呼び出される場合、Kotlinでは例外を捕捉する必要がありますか？

いいえ。チェック済み例外はKotlinコンパイラによって無視されるため、明示的に捕捉する必要はありませんが、実行時にスローされる可能性があります。

一般的なエラーとアンチパターン

不要なすべての例外を捕捉すること（catch (e: Exception)）— 正しく処理できないものを捕まえています。
finallyの誤った使用— 戻り値の変更や例外をスローすること。
Kotlinコード内でthrows宣言を使用しようとすること。

実生活の例

ネガティブケース

どこにでもcatch (e: Exception)を挿入し、実際のエラーと予期されるエラーを区別していません。finallyで戻り値を使用し、不正な動作を引き起こす結果となります。

メリット：

すべての障害に対して非常に耐性のあるコード

デメリット：

デバッグが困難
エラーメッセージとその発生原因が失われる
実際の問題が隠される

ポジティブケース

予期されるエラーのみを捕捉し、finallyはリソースのクリーンアップにのみ使用し、try/catchは可読性を向上させる場所で式として使用します。

メリット：

読みやすく、メンテナンスしやすく、テストしやすい
透明なエラーハンドリング

デメリット：

API設計と例外処理において規律が必要