イントロ(Eric Lippertブログから):
厄介な例外は、不幸な設計上の決定の結果です。厄介な例外は、完全に例外ではない状況でスローされるため、常にキャッチして処理する必要があります。
厄介な例外の典型的な例はInt32.Parseです。これは、整数として解析できない文字列を指定するとスローされます。ただし、このメソッドの99%のユースケースは、ユーザーが入力した文字列を変換することです。これは古いものである可能性があるため、解析が失敗することは決して例外ではありません。さらに悪いことに、呼び出し元は、メソッド全体を実装せずに引数が悪いかどうかを事前に判断する方法はありません。その場合、最初に呼び出す必要はありません。
ここで重要な部分:
この不幸な設計上の決定は非常に厄介だったので、もちろんフレームワークチームはその後すぐにTryParseを実装しました。これは正しいことを行います。
MSDN Int32.TryParseから:
戻り値タイプ:System.Booleansが正常に変換された場合はtrue。それ以外の場合はfalse。
そのため、同僚は最近、文字列が数字かどうかを確認する必要のある小さなコードに取り組んでいたので、それについて考えて、良いC ++ソリューションがないことに気付いた後(基本的にはfor__each / find_ifまたはboost:lexical_cast try catchです)is_convertible
ブーストから何かを持っているとどれほど素晴らしいでしょうか?
多くの場合、ブーストlexical_cast
をラップして、tryブロックの最後でtrueを返し、catchブロックの最後でfalseを返すことができますが、既存のプラクティスを好みます:)ソリューション。