ParseとTryParseを実装するなら

質問

こんにちは。c#初心者です。

　c++にも、c#にもintにParseメソッドと、TryParseメソッドがあると思いますが、intのように比較的簡単に解析できるもの（比較的簡単なメソッド）ならParseメソッドをコピペして、例外の部分を「return false;」に変えるだけで十分だと思うのですが、問題は、Color構造体のような（やや）複雑なものです。

　R, G, Bに加え、α値があり、また、名前で色を表す可能性もあります。考えただけで（intと比べると）かなり面倒なメソッドになることが分かると思うのですが、とりあえずParseメソッドを実装したとしましょう。
　次にどうせならTryParseメソッドも実装したいところなのですが、初心者が考えた方法は３つあります。

１、Parseメソッドをコピペして（FormatExceptionなどの）例外部分を「return false;」に変える。
２、Parseメソッドをtryブロックに入れて、catchブロックで「return false;」とする。
３、privateなtryParseメソッドを用意し、それをベースにする。戻り値はException型で、Parseメソッドではnullで無ければスロー、TryParseメソッドでは「return exception == null;」とする。
（ソースコードは一番下）

　１は保守性上、少々問題ありかと。２は利用側がちょっと楽になることには変わりないが、パフォーマンス重視には向かない（というかテキストを解析している時点でパフォーマンス低いかな？）、３は１、２の問題を克服しているもののこのような設計でよいのか自信なし。

　という訳で悩んでいます。どれが一番良いでしょうか？　もっと良い案があればそれでも良いです。どなたかわかる方がいらしゃいましたら教えてください。

----------- 簡易ソースコード --------------
c#で書いています。また読みやすく（なっているかどうかは分かりませんが）するため、１行で書けるところも２行以上で書いている部分もあります。

案１

public static Color Parse(string text)
{
　　……
　　if ( invalid ) throw new FormatException();
　　……
}
public static bool TryParse(string text, out Color result)
{
　　……
　　if ( invalid ) {
　　　　result = Color.Empty;
　　　　return false;
　　}
　　……
}
------------------------------------------------

案２

public static Color Parse(string text); // 略
public static bool TryParse(string text, out Color result)
{
　　try {
　　　　result = Parse(text);
　　　　return true;
　　}
　　catch ( FormatException ) {
　　　　result = Color.Empty;
　　　　return false;
　　}
}
---------------------------------------------------

案３

private static Exception tryParse(string text, out Color result)
{
　　……
　　if ( invalid ) {
　　　　result = Color.Empty;
　　　　return new FormatException(); // スローせずに返す
　　}
　　……
}

public static Color Parse(string text)
{
　　Color result;
　　Exception exception = tryParse(text, out result);
　　if ( exception != null ) throw exception;
　　else return result;
}

public static Color TryParse(string text, out Color result)
{
　　Exception exception = tryParse(text, out result);
　　if ( exception == null ) return true; // 例外が無ければ成功
　　else return false;
}

回答No.3

επιστημη（@episteme） · ベストアンサー

throw/catchにかかるコストを考慮/実測した結果であるなら案３でいいんじゃないかしら。
例外オブジェクトをnewするだけならさほどのコストはかからなさそうですし(念のため実測するが吉)。
new するコストがバカにならんなら:

enum err_code { no_err, format, overflow, ... };

private static err_code tryParse(string text, out Color result) { ... }

public static Color Parse(string text) {
Color result;
switch ( tryParse(text, out result) {
case err_code.format: throw new FormatException();
case err_code.overflow: throw new OverFlowException();
...
}
return result;
}

public static bool TryParse(string text, out Color result) {
return tryParse(text, out result) == err_code.no_err;
}

とか。

お礼

回答ありがとうございます。
　案３でいいのですか。いえ、例外（またはその情報）を戻り値などで返すのは、（サンプルでもあまり、というか全然見ないし）ちょっと気が引けたので、悩んだ挙句質問に至りました。

　もともと文字を解析している時点でかなりのコストがあることは承知の上なので、例外のインスタンス初期化のオーバーヘッドくらいは些細なことかと。

　確かに列挙体を使えばより高速かもしれませんが、例外の方が可読性や、保守性がちょっと上かなと思ったのがあります（単純に列挙体が思いつかなかったのもありますが……）。

　それと、もうひとつ。一時期、「何とかして例外を使わずにコードを書くぞ！」と変な方向にがんばっていた時期がありまして、そのときの失敗（主に保守性と拡張性の欠落）の経験から、そういう目的での列挙体の使用がはばかれるというのがあります。

　一応、３，４つのサンプルで実測してみましたが、例外の無い場合は、案２の方が案３より高速（とはいっても数値ですらほとんど変わらず、体感時間に変化なし）で、２０以上の例外があるようなら、案２の方が体感速度にも影響が出る程度の時間の遅れはありました。
　無論、コピペの案１は（ちょっとだけ）高速ですが、修正が面倒でした。

回答No.2

επιστημη（@episteme）

> ちょっと神経質になりすぎでしょうか？

実測してみてはいかがです?

僕なら bool TryParse(string test, out Color result) を実装し、
Color Parse(string test) {
Color result;
if ( TryParse(test, out result) ) return result;
else throw new FormatException();
}
かな。

お礼

回答ありがとうございます。確かにその方法もあるのですが、それでは「FormatException」以外の例外、つまり例えば「OverFlowException」も発生する可能性があるのにそれに対応できないことです。それで
Exception tryParse(string text, out Color result)
をベースにしようと考えました。
　いまさらですが、このtryParseは名前か引数を変えるかしてpublicにしてもいいような気がするのですが、「例外が発生したことを戻り値や引数で表してはいけない」と言うような話も聞いたような覚えがあるので分からないです。
　また、（Color構造体は変わらないでしょうが、それ以外で）後々に仕様が変わって、発生する例外が変わっても修正する部分はわずかです。多分この程度ならYAGNIと言われないと思うのですがどうでしょうか？

補足

言い忘れていました。例外が発生というのは「案２」を用いて、TryParseを実装した場合、そこで例外が発生し、その例外がハンドルされるという意味です。
　記憶違いでなければ、例外処理は他の普通の処理（ O(n^3), O(2^n) 程ではない処理）と比較するとべらぼうに遅かったと思います。

try { throw Exception }
catch ( Exception ) { }

これをリリースコンパイル（最適化オン）に設定して、forでまわしてみると、平均12msでした（ノートPCで、CPU: 2.40GHz×2）。

回答No.1

επιστημη（@episteme）

どれも大差ないんじゃないかと。
パフォーマンスを気にするほど頻繁に呼ばれるとも思えないし。

お礼

回答ありがとうございます。
　確かに”頻度”は高くないのですが、”一気”に使われる可能性があります。
　例えばHtmlのようにバイナリデータに変換せずにそのままテキストデータとして保存する場合、それを読み込む際、それなりの量の（合計して１０～２０ｋＢ）文字列が入力されることを想定しているので、その際、こんなところで例外が連発していたら、それなりに速度が低下すると思います（１回当たり12ms換算で100回起れば1.2秒）。
　0.5秒で遅いと思われる、1.0秒で不機嫌になる人続出、と聞きましたが、ちょっと神経質になりすぎでしょうか？