- PR -

C# 戻り値の型を動的に変更することは可能ですか？

«前のページへ 1|2|3|4|5|6|7|8|9|10|11 次のページへ»
投稿者投稿内容
未記入
ぬし
会議室デビュー日: 2004/09/17
投稿数: 667
投稿日時: 2005-05-10 13:11
なんだか はぐらかされてるだけのような気がしてきました。

引用:
引用:
どこまでを「想定の範囲」とするか、明確にする必要があると思います。

「想定の範囲」は結局アプリケーションに依存するためでしょう。

はじめは「想定の範囲」は 人に依存すると仰っていませんでしたか？ 「想定の範囲」が、人に依存するかアプリケーションに依存かでは全然、違いますよね。「想定の範囲」(つまりフローの続行可能性)が、アプリケーションに依存するのは、まったく同意しますが、人に依存する と言われると、それってガイドラインとして機能するの？ と感じてしまいます。

引用:
#経験に左右されずに同じような設計／コーディングができる、、、
#これだと、私の給料は上がりません。

経験に左右されずに同じ設計・コーディングができると言っているのではなく、経験に関係なくビギナーもベテランも従うべきものがガイドラインやルールではないでしょうか？ ということだと思います。
前川
常連さん
会議室デビュー日: 2004/04/27
投稿数: 38
お住まい・勤務地: １DK
投稿日時: 2005-05-10 16:05
プログラミングはJavaから入門した者です。
今まさに、例外を忌避するようなVBのソースを目にして文句を言いかけていた所でした。このスレッドのお陰で恥をかかずに済みました。

そのソースなんですが、全ての関数が
コード:
Private Function fun_get_aaa(ByVal arg As String, ByRef aaa As String) As Boolean
    fun_xxx = False
    Try
        ... いろいろ処理 ...
        fun_xxx = True
    Catch ex As Exception
        ... 例外ハンドリング ...
    End Try
End Function
となっています。一般的に言われる”戻り値”は「正常・続行：True、異常・中止：False」に統一、本当に欲しい値はref/outで、というルールになっているのです。もちろん呼び出し側は常に
コード:
    If Not fun_get_aaa(arg, aaa) Then
        ... 異常時の処理 ...
        Exit
    End If
    ... 正常時の処理 ...
となっています。2005-05-02 09:40のJittaさんの例とは違ったやり方ですね。
初めて見た時は頭を抱えましたが、例外は避けたい・戻り値にも特別な意味を含ませたくない、という考えで行くと、こういう手もアリなんですね。


…何か間違っている…


余談ですが
引用:
#経験に左右されずに同じような設計／コーディングができる、、、
#これだと、私の給料は上がりません。
早くそういう世界になるといいですねえ…
nodera
大ベテラン
会議室デビュー日: 2003/09/08
投稿数: 200
投稿日時: 2005-05-10 17:02
こんにちは。

>今まさに、例外を忌避するようなVBのソースを目にして文句を言いかけていた所でした。このスレッドのお陰で恥をかかずに済みました。

あう、このスレでそんな認識にいたってしまったのですか・・・。
自分だったらすぐ文句いいますよ。
「もし”いろいろ処理”を行っている最中に、OutOfMemoryExceptionやStackOverflowExceptionが発生したらどうするの。なんでもかんでも呑み込んで、あらゆる状況から異常処理で復旧できる可能性はあるのか」と。（そもそも、要求側はそれが発生したことすら分からないままかもしれない）

＃あ、言及しているのは「Catch ex As Exception」の部分です。
＃例外を結果コードに変換するとは、ちと論点がずれたかな？

[ メッセージ編集済み 編集者: nodera 編集日時 2005-05-10 17:09 ]
nanbu
大ベテラン
会議室デビュー日: 2004/08/19
投稿数: 178
投稿日時: 2005-05-10 17:24
引用:

未記入さんの書き込み (2005-05-10 13:11) より:
なんだか はぐらかされてるだけのような気がしてきました。

はじめは「想定の範囲」は 人に依存すると仰っていませんでしたか？ 「想定の範囲」が、人に依存するかアプリケーションに依存かでは全然、違いますよね。「想定の範囲」(つまりフローの続行可能性)が、アプリケーションに依存するのは、まったく同意しますが、人に依存する と言われると、それってガイドラインとして機能するの？ と感じてしまいます。

南部です。

申し訳ございません。
「想定の範囲」が人に依存するのではなく、
あるアプリケーションを設計・コーディングする際に、
業務エラーとして想定できる範囲やその「想定の範囲」が
適切がどうかの判断は経験や知識によって変わる、です。

もし、私がよく知らない基幹システムを設計したら、
「それくらいは、想定してよ。」
と言われること請け合いです。

これの元になっているJittaさんの例は次のものですが、
私の理解力不足により、誤解を招いたことをお詫びします。

引用:

Jittaさんの書き込み (2005-05-08 21:43) より:

　想定されている例外が「業務エラー」なら、たとえば数値を入力するところで、「ここには『数値を表すラベル』を付けているのだから、数値以外の入力はない」と思いこんでいれば、想定されない例外が発生します。そして、プログラミング初心者は、そういうコーディングをよくするでしょう。
　しかし、「どんなリードの仕方をしても、ユーザは何を入力するかわからない」という前提に立てば、想定された例外が発生します。
　とすると、設計者やコーディング者の経験や知識によって、変わるのでしょうか。

前川
常連さん
会議室デビュー日: 2004/04/27
投稿数: 38
お住まい・勤務地: １DK
投稿日時: 2005-05-10 17:27
おお、メモリ不足もExceptionで上がってくるとは！ってErrorが無いんだから当然ですね。Java脳が抜け切って無い…

>あう、このスレでそんな認識にいたってしまったのですか・・・。

スミマセン、一応そこは冗談です。どうした物かと(このスレッドを眺めつつ)考察継続中です。
# 多分「一応フェールセーフだから」とかで終わりだろうなあ

>ちと論点がずれたかな？

私が無駄に汚してしまいました。失礼しました。
甕星
ぬし
会議室デビュー日: 2003/03/07
投稿数: 1185
お住まい・勤務地: 湖の見える丘の上
投稿日時: 2005-05-10 17:38
引用:

前川さんの書き込み (2005-05-10 16:05) より:
プログラミングはJavaから入門した者です。
今まさに、例外を忌避するようなVBのソースを目にして文句を言いかけていた所でした。このスレッドのお陰で恥をかかずに済みました。

いや、VBのソースで例外が忌避されるのは、単にVBの例外が使いずらいからだと思いますよ。

・トラップする例外を限定することが出来ない。全ての例外をトラップした上で、エラー番号(これも相関するエラー番号が隣接していれば救われるけどバラバラ)をチェックし、不必要なエラーを再びRaiseするしかない。
・ユーザー定義例外が使い難い。「エラー番号に513 〜 65535の値を使え〜」となっているが重複を回避するための仕組みがない。しかもランタイムの例外と挙動が微妙に違う(^^;

ユーザー定義例外を頑張って使ったり、エラー値を例外を混在させたりするぐらいなら、エラー値を返すように置き換えちゃった方が楽と言う考え方は有りだと思います。実際、VB6.0で構造化例外を使い込んでいる人なんて、滅多に居ないんじゃないでしょうか？"Raise VB6.0"でぐぐっても、殆どヒットしないし。
梅吉
会議室デビュー日: 2003/08/19
投稿数: 16
投稿日時: 2005-05-10 18:05
例外の話は9ページにわたって議論しなければならないほど
分かりづらいのですね。

最終的にどなたか箇条書きでまとめて頂けませんか？
素人でもわかるように...。
（箇条書きで書けるようなら9ページにわたって討論していないのでしょうか？？？）
甕星
ぬし
会議室デビュー日: 2003/03/07
投稿数: 1185
お住まい・勤務地: 湖の見える丘の上
投稿日時: 2005-05-10 18:52
＃まとめる前に私の判断基準を書かせて下さいませ〜

例外をThrowするか、エラー値を返すかは、その状況がリカバリー可能か否かで分けています。

入力された値が仕様上定められた範囲内か否かは、当然値が入力された直後に行われているものと思います。少なくとも中堅以上のエンジニアなら、入力値をチェックする処理ぐらい入れてくれると思っています。仕様上定められた範囲内であるにもかかわらず、演算を継続不可能なエラーが発生したとしたら、それは仕様やソフトウェアのバグ以外はありえません。処理を中断する(エラーを通知する)以外の有効なリカバリー手段を講じることは出来ないでしょう。この場合は例外を用いて通知した方が効率が良いです。

もし入力された値が妥当なものか否かを単純に判断することは出来ず、実際に演算を行ってみる必要があるならば、エラー値を返すのは有りでしょう。ソフトウェアはエラー値を受けて、ユーザーにパラメータの再入力を促すなど、有効なリカバリー手段を取り得ます。

でも実際のアプリケーションで、後者のようになる事は滅多に無いと思うんですよね。殆どの場合、例外が発生したときに出来ることは、処理を安全に中断することと、エラーを通知することだけだと思います。
«前のページへ 1|2|3|4|5|6|7|8|9|10|11 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）