Rustがtry-catchの例外機構を持たない理由は非常に単純で
(A) 本質的にリカバリできることは通常のエラー処理だけで十分に対処可
(B) 本質的にリカバリできないことはpanic
前者の(A)では関数がResult<T,E>で返しそれがエラー時Err(E)の時に
処理をスルーして上位へ移譲したいならfunc()?と?を1文字付加だけで済む仕組み

一方で(B)の「本質的にリカバリできない」panicとは具体的に次のどちらかとなる
(1) プログラムに論理的な間違いがある場合
(2) 何らかのリソース不足になった場合

この(1)は具体的に以下のようなケースがある
- ありえない状況に陥ってプログラマー自らpanicさせる場合
- 一部の標準ライブラリに対してありえない値を渡した場合
- 配列などで範囲外のインデックスで操作しようとした場合
- ResultやOptionで正常値でない時にunwrap()した場合
- RefCellやRwLockで実行時借用ルールを犯した場合
これらはプログラムに論理的な間違いがある場合のみ生じるためエラー処理とは本質的に異なる

一方で(2)の「何らかのリソース不足になった場合」は
プログラム自体には論理的なミスはないが何らかが溢れた以下のケース
- 数値型が溢れて計算を続行できない場合
- ヒープが溢れて新たにアロケーションできない場合
- スタックが溢れて新たに関数呼び出しができない場合
このうち数値溢れ演算はpanicを起さないチェック付き演算で置き換えて回避可能
アロケーションもpanicを生じさせないアロケーターを作ることで回避可能

＃ ちなみに「リカバリできないことはpanic」の考えはクロージャ単位にまで拡張されていて
＃ panic::catch_unwind(クロージャ)を使うとResult<T,E>を返しpanic時にErr(E)を得られるため
＃ そのクロージャ自体は内部でリカバリできないがpanic発生を捕捉すること自体は可能

このようにRustでは曖昧な存在である『例外』を廃して
通常のエラー処理と真の異常時であるpanicの二種類に分けて扱っている