博士

ロボ子、今日のITニュースは「Tritium」っていうプロジェクトが、安定したデスクトップ環境を目指してるって話じゃ。

ロボ子

安定したデスクトップ環境、ですか。具体的にはどのような取り組みをされているのでしょう？

博士

ふむ、どうやらRustのボローチェッカーってやつが、メモリ破壊を防ぐのに役立ってるらしいぞ。メモリ安全は安定性の基本じゃからな。

ロボ子

確かに、メモリ破壊は深刻な問題を引き起こしますから、ボローチェッカーは非常に有効ですね。

博士

そうじゃろ、そうじゃろ。で、安定性ってのは、クラッシュとかデータ破損を避けることらしい。

ロボ子

なるほど。エンドユーザーにとって、クラッシュは最も避けたい事象の一つですね。

博士

そこでじゃ、Tritiumでは「パニックの回避」ってのを重要視してるみたいじゃ。

ロボ子

パニック、ですか？

博士

そう、パニック！開発段階ではパニックは便利だけど、エンドユーザー向けには、クラッシュするより、エラーが起きても続行して、ユーザーが作業を保存して再起動できるようにする方が親切じゃろ？

ロボ子

確かにそうですね。開発者視点とユーザー視点では、優先順位が異なるということですね。

博士

そういうことじゃ。デバッグモードでは、エラー発生時のスタックトレースを記録して、その場でデバッグできるようにするらしい。

ロボ子

スタックトレースがあれば、エラーの原因を特定しやすくなりますね。

博士

`panic_or_return`マクロを使うと、`Result`や`Option`のunwrap時にパニックの代わりに早期リターンやデフォルト値を返せるらしいぞ。

ロボ子

それは便利ですね！でも、どのような場合に使うべきなのでしょう？

博士

早期リターンやデフォルト値がユーザーにとって明白で、上流の`Err`や`None`の処理と一貫性がある場合にのみ使うべきらしい。

ロボ子

なるほど、安易に使うと予期せぬ動作につながる可能性があるということですね。

博士

その通り！それから、再帰の制限も重要じゃ。

ロボ子

再帰、ですか？

博士

Docx仕様みたいな複雑なデータを扱う場合、再帰処理はスタックオーバーフローを引き起こす可能性があるからの。

ロボ子

スタックオーバーフローは怖いですね...

博士

Tritiumでは、再帰の代わりに、反復的なパターンを使って、最大ページ数を超えないように制限してるらしい。

ロボ子

再帰を避けることで、スタックオーバーフローのリスクを減らせるのですね。

博士

そうそう。デバッグビルドでは、制限に達するとパニックが発生するけど、リリースビルドでは、段落をサイレントに切り捨てるらしいぞ。

ロボ子

リリースビルドでは、ユーザーに影響を与えないように、サイレントに処理するのですね。

博士

制限値を十分に高く設定することで、ユーザーはエラーに気づき、回復、アンドゥ、再起動できるって寸法じゃ。

ロボ子

ユーザーエクスペリエンスを考慮した設計ですね。

博士

じゃろ？じゃろ？ところでロボ子、安定したデスクトップ環境って、まるで私の研究室みたいじゃな。いつも実験が爆発寸前だけど、なんとか安定してる…みたいな？

ロボ子

博士の研究室は、ある意味、カオスの中に秩序がある…と言えるかもしれませんね。

博士

褒め言葉として受け取っておくぞ！