ふらっと C#,C♯,C＃（初心者用） Part148

■ このスレッドは過去ログ倉庫に格納されています
2020/05/27(水) 10:14:39.92ID:wHIUQvvs
■前スレ
ふらっと C#,C♯,C＃（初心者用） Part147
http://mevius.5ch.net/test/read.cgi/tech/1582100741/
■関連スレ
C#, C♯, C＃相談室 Part94
http://mevius.5ch.net/test/read.cgi/tech/1553075856/
■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/

■情報源
https://docs.microsoft.com/ja-jp/dotnet/standard/class-libraries
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/index
https://docs.microsoft.com/en-us/dotnet/standard/class-libraries
http://referencesource.microsoft.com/
・Insider.NET > .NET TIPS - ＠IT
https://www.atmarkit.co.jp/ait/subtop/features/dotnet/dotnettips_index.html
・DOBON.NET　.NET Tips
https://dobon.net/vb/dotnet/index.html
2020/06/05(金) 22:07:18.81ID:G2EzgRxv
>>109
古いからって理由だと思う
2020/06/05(金) 22:13:26.64ID:G2EzgRxv
でもマイクロソフトも新規機能は付けないって言ったり
vbオワコン感あるね
今からやるのは絶対避けた方がいいな
112デフォルトの名無しさん
垢版 |
2020/06/05(金) 22:35:39.50ID:td6kQI8l
そうざますかなるほど
2020/06/06(土) 23:27:10.97ID:Ty36+cj5
>>109
オブジェクト指向言語に寄せていくとC#とかJavaみたいなシンタックスになっていくって聞いたことある。VBみたいな書き方は向いてないんだって。
2020/06/07(日) 11:35:44.28ID:s05OkEKn
自分をオブジェクト指向だと思い込んでる手続き型言語のイメージ
クラス定義をしてるというよりも、クラス定義をする命令を書いてる感じがする
End句とか特に
2020/06/07(日) 11:36:39.69ID:s05OkEKn
ごめん
意味不明な事書いた

忘れて
116デフォルトの名無しさん
垢版 |
2020/06/07(日) 12:01:10.67ID:OpsuUylK
>>113
なるほどVBはオブジェクト指向に対応してないと。
これですっきり理解できました。
117デフォルトの名無しさん
垢版 |
2020/06/07(日) 12:07:01.26ID:bN0eQpRN
>>116
納得しちゃダメw
118デフォルトの名無しさん
垢版 |
2020/06/07(日) 13:34:29.22ID:ABh2E5hx
誰得
119デフォルトの名無しさん
垢版 |
2020/06/07(日) 13:38:21.36ID:ysGPyHPQ
IT掲示板群 ttp://x0000.net/forum.aspx?id=15

学術の巨大掲示板群 - アルファ・ラボ ttp://x0000.net
数学 物理学 化学 生物学 天文学 地理地学
IT 電子 工学 言語学 国語 方言 など

simulationライブラリで純粋な関数式プログラミングをする
ttp://x0000.net/topic.aspx?id=3631-0
UIライブラリ (C#, 2D) を作ったよ
ttp://x0000.net/topic.aspx?id=3688-0
連続と離散を統一した！
ttp://x0000.net/topic.aspx?id=3709-0
4Dエンジン（画像有り）
ttp://x0000.net/topic.aspx?id=3677-0
matrixのライブラリ
ttp://x0000.net/topic.aspx?id=3711-0
ある強力なFor関数
ttp://x0000.net/topic.aspx?id=3630-0
SQLライブラリ
ttp://x0000.net/topic.aspx?id=3675-0

PS malloc / free を実装してみた (C#)
ttp://up.x0000.net/files/TMallocTest.zip
2020/06/07(日) 15:21:59.81ID:HbOCC7H8
ネイティブアプリを作ってるのですが、
パスワードがかけられたファイルをオープンしたりしようとしています。
コンパイルされるからパスワードはコードにリテラルで書こうと思っています。
が、
c#のコンパイル物の逆コンパイル性はかなり容易なのでしょうか？
Javaはコンパイルしても逆コンパイルで全部戻せれるそうですが。
2020/06/07(日) 15:26:10.81ID:RWTT3Yr/
>>120
C#の逆コンパイルはフリーウェアでほぼ完全にできるレベル
2020/06/07(日) 15:26:15.58ID:BQDkQ1pk
>>120
一瞬で逆コンパイルできるから、ソースにパスワード埋め込んだ状態で配布するとか論外
2020/06/07(日) 15:27:26.51ID:BQDkQ1pk
>>120
てかVisual Studio使ってるなら簡単に逆コンパイルできるの知ってるやろ？omnisharpですら最近できるようになったし、昔からilspy等はよく使われてる
2020/06/07(日) 15:45:43.26ID:YQeR/K+2
パスワード判定アプリだけc++で書いてc#からキックするって手もある
わかるやつにはわかっちゃうけど
2020/06/07(日) 15:48:05.93ID:a/lkIPFo
>>120
クライアントに配布する時点で秘匿は無理だと思え
126デフォルトの名無しさん
垢版 |
2020/06/07(日) 15:50:18.31ID:MDOjbT3v
ここもVBA質問スレのレベルかね
2020/06/07(日) 16:56:57.78ID:odk7pmo/
そもそもネイティブアプリって何さ？
2020/06/07(日) 16:59:43.95ID:BQDkQ1pk
>>127
Webアプリに対してクライアント側だけで動作するアプリ、って意味合いでネイティブって言ってるんだろな
2020/06/07(日) 17:00:17.90ID:DbjJE1m7
>>126
重複の上テンプレさえ不完全にされた失敗スレに何を期待しているの？
>>127のようにグーグル検索すら使えない人が来るのに
2020/06/07(日) 17:11:15.20ID:dzDK5z44
パスを見られたくないのなら認証されたユーザーからの要求があった場合にはサバ側でパス保護ファイルを開いてそのバイナリをネットで送るって形にするしかないな
131デフォルトの名無しさん
垢版 |
2020/06/07(日) 22:07:54.57ID:6TqvWrlZ
そんな糞めんどくさいことしなくてもインストール時か初回起動時に
ユーザーにパスワード（っていうか復号コードだと思うけど）を入力してもらえばいいでしょw
2020/06/07(日) 23:42:30.31ID:+YSUT0gy
Ruby on Rails では、

暗号化キーのmaster.key は、Github へ保存しないけど、
暗号化済みのcredentials.yml.enc は保存する

それを、master.key で復号すると、YML 形式で、下のような設定が書いてある

aws:
access_key_id: 123
secret_access_key: 345

つまり、暗号化済みの文字列は、公開しておいてもOK。
キーが分からないので、復号できないから

逆に、キーは公開したり、アプリ内に含めるとダメ！
2020/06/08(月) 07:22:56.58ID:yGStluWB
例外って一度考え始めちゃうとめっちゃ難しいな
色んなサイトのコードとか見てると例外を乱用してるようにしか見えないものが多いように感じる(特にネットワーク関連)
だからといってどこを例外にすれば正しいコードになるのか全然わからん
やっぱり例外処理は全く使わないで済むようにくらいの勢いで想定される例外を自力で検出するのが一番良いんだろうか
2020/06/08(月) 07:36:06.86ID:SQAF69LT
>>133
なんか基準があるはずよ
落ちるのだけはやめてって言われてるなら
GUIの操作するメソッド全部でcatchしてメッセージでも出さんといかんじゃん
それとも「ああ、死んじゃっていいよ」って言われるかもしれんし
この場合は何もしないし
「ログにだけ出して」
ってのもあるし

そもそも各クラス例外を出す方針に一貫性がない
開こうと思ったファイルが開けないときの動作は普通は例外にしたくないけど例外が飛んでしまうときはcatchしないといけないわけで
まあ、個別に対処が必要？
2020/06/08(月) 07:41:47.96ID:CwjbcTvy
Rubyの話をする奴は、ちょっと話が違うとか理解することはできんのかな。
2020/06/08(月) 07:45:18.91ID:CwjbcTvy
>>133
例外は、Catchしたとて復帰不可能なものはアプリケーションエラーにして落とすのに使ってるかな。
そのメソッド内で完結できるならばCatchするというか。
後始末してから結局throwするケースもあるけど。

上っ面がアプリケーションからバッチ処理に変わっても同じように使える事、ぐらいを想定して例外処理書くと統一感出ると思うよ。
2020/06/08(月) 09:12:40.55ID:yGStluWB
>>134
自作だからその辺りの基準はないなあ
とはいえ世間でも基準は割とバラバラなのか
今回作ってるのはネットワーク関連のクラスなんだけど、初めて手を出す分野だからどれが個別に対処できるかは正直よくわかってないんだよね
参考にしてる資料に忠実に作ったら、ちゃんと動くんだけど例外処理だらけなのが見ててすごく気持ち悪くて、これで本当に正しいのかわからなくなったというか

>>136
使い分け方参考になります
あまり考えたくなったけどちゃんとしたものを組むなら例外の内容毎にきちんと仕分けしなきゃだめなのか・・・なんか逆にどんどん複雑になりそうで胸が熱くなるな
こう考えると寧ろサンプルはシンプルに纏まってて良いものに感じてきたわ

例外は普段最低限しか使用しないものだからイメージできなかったけど二人のお陰でなんとなく輪郭が見えてきた気がする、ありがとう
2020/06/08(月) 11:34:14.50ID:dXkaUtDt
例外は１つ残らず握りつぶせ
2020/06/08(月) 12:23:59.18ID:CwjbcTvy
>>137
例外って究極のgotoだからね。
その場でやっつけないなら慎重に受ける場所とその後の動きを検討しないといかんよ。
毎回その場でやっつけて、エラーとして呼び出し元に帰すって方針ならそれはそれでいいかも知れんけど、
誰かキャッチするだろって方針で、続行不能だからと適当に例外吐いて落とさせてると、あとで困る。特にバッチ処理。
2020/06/08(月) 13:24:22.92ID:MRA6597x
https://ufcpp.net/study/csharp/misc_exception.html
2020/06/08(月) 14:31:54.71ID:T+olwkzM
>>135
そいつはこの板のあちこちに出没する有名な荒しだからスルー推奨。
いくら指摘しても自分に都合のいい話しか目に入らないから相手するだけ無駄で、スレを汚すことになる。
2020/06/08(月) 14:45:08.81ID:XmX+evHg
>>133
エラーハンドリングの基本的な考え方はこのシリーズ読むと良いと思う
https://docs.microsoft.com/en-us/archive/blogs/nakama/293
2020/06/08(月) 21:31:29.92ID:g8QOms8D
>>138
これはネタで書いたんだろうけど、例外は適切な場所で握りつぶすのが大事だよな。
「知ってる例外はcatchするけどあとはスルー」ってのが最悪。
2020/06/09(火) 05:12:12.64ID:qGXJUMNV
色々資料をご紹介いただきありがとうございます
つまり、例外が大好きな.NETを呪いながら潰せる例外はメソッド内で潰し、潰せなければどのような例外があったかをきちんと調べられるようにすれば良いわけかな
今回は例外が発生してもクラッシュせず、かと言ってメソッド内で処理する事はできないようにする予定なので、例外が発生する可能性があるメソッド全てに例外の種類を特定できるような戻り値を与える方向で進めていく予定でやってみます
2020/06/09(火) 05:30:56.43ID:pfkm8l8b
例外が出る処理はすべてcatch書いて適切な処理を書けばいいだけ。簡単。
2020/06/09(火) 07:53:14.85ID:JJE9ezaH
>>145
どこでどんな例外が発生するかを全部把握して漏れなくやるのはそれなりに大変だなあ
2020/06/09(火) 08:08:09.91ID:iKljlpbe
>>146
かといって、Javaの検査例外の仕組みはちょっとフットワークが重たくなるんだよな。
あれ自体は悪い仕組みじゃないどころか、発想としては初期の割に進んでたんだけど。
2020/06/09(火) 08:50:30.25ID:1J1p6pRh
全ての例外をcatchすればいいんじゃね？
2020/06/09(火) 09:04:01.05ID:khWV6688
後にも先にもJavaしか採用していない悪い仕組みだよ
呼び出し階層の途中をすっ飛ばして高層階と低層階の間で例外の関心が繋がるという、
高階関数やフレームワーク等において普通に存在する極めて重要な例外のユースケースを検査例外は無視している
2020/06/09(火) 09:29:05.21ID:iKljlpbe
うーん、むしろ、例外が漏れるケース、throwsを書かざるを得ないケースってのを減らすべきだと俺は思ってたけどなぁ。
低層階で発生したものを高層階でハンドリングする事が正しいとはあんまり思わんな。
IOのExceptionみたいな、高層階側ではどうしようもない事を上げられても困ると思う。
2020/06/09(火) 09:44:56.94ID:xkuk2TPr
検査例外ほんと楽
2020/06/09(火) 10:19:25.97ID:LXNCuYlO
けんされいがいって何だろうと思って調べたんだが、素人目には良い仕組みに見えてしまった
ただ例外を前提にするなら、もはや例「内」のような気が
2020/06/09(火) 10:21:47.06ID:0Ox9n+fW
Anders Hejlsbirgの検査例外に対する批判
https://www.artima.com/intv/handcuffs.html
検査例外は失敗、とっくの昔に結論出てる
2020/06/09(火) 11:04:45.35ID:V/up5vUs
高層側でどうしようもない例外が上がってきてるならそれは下層側が間違ってるだけでは
2020/06/09(火) 11:27:54.89ID:/rzxY16Z
>>149
>後にも先にもJavaしか採用していない悪い仕組みだよ
Swiftで採用されてるよ
シグニチャによって呼び出し側にエラーハンドリングを強制する方法自体は悪い仕組みではない
例外ではないがRustも考え方としては同じだし>>142の赤間さんの考え方もベースは同じ
2020/06/09(火) 11:29:03.56ID:iKljlpbe
チェック例外の発想は悪くないしいい機能だと思うけど、Javaのやりかただとバージョニング諸々で破滅的な事になりがちだから、静的解析なりなんなりのツールで確認すべきかなーっていう主張に読めたんだけど？
2020/06/09(火) 12:02:30.29ID:GiCu1zyF
何の例外がくるのか意識してかけ派なのか
何の例外も気にするな派なのか
そのどちらであっても書き手の例外テロに強制的に付き合わなければならない
そのごった煮であることを受け入れた上でプロジェクトのスタンスを決めなければならない
2020/06/09(火) 12:06:21.98ID:0Ox9n+fW
>>155
Swiftの例外宣言は「例外を投げる」という指定ができるだけで、型の指定はないよ
>>153の話で言えば、あらゆるメソッドにthrows Exceptionが付けられて破綻した状態を正しいものとして受け容れてるわけ
2020/06/09(火) 12:32:13.75ID:+J3ztXKO
>>150
呼び出し階層が関心事の包含関係を反映しないケースは普通にある
ラムダなんかいい例で、君は x.Select(y => y.Hoge) でSelectがHogeの投げる例外を知っていなければならないと言ってるんだよ
160デフォルトの名無しさん
垢版 |
2020/06/09(火) 12:43:43.58ID:XPvdX8TV
>>144
例外をエラーコードに変換して何の意味があるのw
例外の発生個所でそれを適切に処理できないなら何もしなくていいでしょw
後々のメンテナンスを考えて、あえてcatchして再スローするコードを書いておくのはありだとは思うけど。
2020/06/09(火) 12:50:07.05ID:LXNCuYlO
>>149
関心が繋がるって意味が分からないんだが、要するに因果関係があるってこと？
2020/06/09(火) 13:18:10.16ID:iKljlpbe
>>159
俺の主張は違うよ。
Hogeは例外を投げてはいけないと言ってるつもり。
2020/06/09(火) 17:30:22.31ID:aSDBpvhy
>>162
例外を投げることを主張するばかりか、それを上位で処理することを強要する仕組みに賛同してなかったか？
2020/06/09(火) 17:38:45.69ID:SzX0azwe
>>163
してないよ。
上位で拾うならアプリケーションを落とすぐらいしかやりようがないって言ってるんだけど。
throwsを書かざるを得ないケースの逆の、書かないケースってどう言う事かわかる？
そのメソッドでは例外が発生しないって事になってるって事だよ。
2020/06/09(火) 17:59:59.91ID:8zzTjSiL
ホント役に立たない議論好きだな
ここから出ないでずっとやっててくれ
2020/06/09(火) 18:18:44.12ID:hAic2KbQ
> IOのExceptionみたいな、高層階側ではどうしようもない事を上げられても困ると思う。
どんなに対処してもFileNotFoundExcpetionって防ぎよう無いけど例外受けてUIでエラー表示とかもしないってこと？
低層でexceptionを捕まえて実装者定義の情報に変えてそれでエラーハンドリングしろってこと？
2020/06/09(火) 19:00:49.38ID:ZQ97UuIm
会社の共有フォルダに配置されており、パソコン起動時に実行されて、特定の時刻になったらトースト出すプログラムを作りたいのですが、どのようなプロジェクトが向いていると思われますか？

WPFのプログラムを起動して5分おきに時刻をチェックし時間になったらトースト通知という仕組を考えたのですが、タスクバーに常駐してるのもなぁと思いまして

スマートな方法がありましたらご教示下さい
2020/06/09(火) 19:03:38.70ID:GiCu1zyF
誰がトリガーなのかイマイチわからなかった
2020/06/09(火) 19:11:59.72ID:TTuCfF7e
>>167
タスクスケジューラとpowershell
2020/06/09(火) 19:13:58.26ID:ZQ97UuIm
>>169
100台近くあるクライアントにタスクスケジューラは辛いです
2020/06/09(火) 19:16:14.88ID:GiCu1zyF
>>169
ワラタ
全部そいつでいーじゃん
172167
垢版 |
2020/06/09(火) 19:26:51.59ID:ZQ97UuIm
クライアントパソコンは起動時に実行ファイルを実行出来る配布済みのものです
実行時に実行ファイルを常駐させる他ないかなと思いつつも適材適所のプロジェクトがあればお伺いしたいなと思っております
2020/06/09(火) 19:30:24.74ID:5mqVZkdG
>>160
.NETがcatchを強要するようなオブジェクトなんかを用意するから悩んでる
結局その場で何もできないなら多くのサンプルコードのように、catchした例外内容をコンソール上に表示する(または再スローする)だけの形が正解でいいのかな？
呼び出し元にも例外処理させるのはあまりやりたくないけどこういうのは仕方ないのか
174デフォルトの名無しさん
垢版 |
2020/06/09(火) 19:43:10.68ID:XPvdX8TV
>>172
別にWindowsのスタートアップに登録して常に起動させておく方法でも問題ないと思うけど、
どうしても嫌なら既に指摘されてる通りWindowsのタスクスケジューラーのタスクに登録すりゃいいでしょ。

ユーザーにそれを手動でやらせろ、と言ってるわけじゃなく、
あなたが作るプログラムがそれをやればいいってことね。
2020/06/09(火) 19:43:33.99ID:5mqVZkdG
.Net介してタスクスケジューラにアクセスできるみたいだし無理ではないんじゃね知らんけど
2020/06/09(火) 19:47:14.39ID:DD0S+2l+
むしろ呼び出し元にも例外処理させるために例外があるんだろ

ファイル書き込みをオブジェクトに任せて書き込もうとしたら書き込めなかった
その後の処理を呼び出し側に書かんでどうすんの？
2020/06/09(火) 19:57:00.94ID:1J1p6pRh
例外をcatchしたらログに吐き出して上位にthrowすればいいじゃん
2020/06/09(火) 20:20:05.71ID:5mqVZkdG
Oh...深く考える必要はなかったってことね
まあ例外に関しては立ち止まって考える機会を得れて十分に学習できたからこれはこれで良かったわ
2020/06/09(火) 20:47:35.88ID:JJE9ezaH
>>149
>呼び出し階層の途中をすっ飛ばして高層階と低層階の間で例外の関心が繋がるという、

それは例外機構そのものの問題だと思うがな。
検査例外はそれを静的にチェックするからすぐ目に付くけど、それ以外の言語は
その関係が動的暗黙的で表に見えないだけ。ある意味よけい悪い。
2020/06/09(火) 21:17:50.01ID:/rzxY16Z
>>173
何もしないならその場でcatchしちゃだめだって
ログ出力のような共通処理は集約例外ハンドラに任せる
2020/06/09(火) 21:23:32.42ID:/rzxY16Z
まず、大原則を覚えてください。

よほどのことがない限り、アプリケーションで try-catch を書いてはいけません。

もう一度繰り返します。

よほどのことがない限り、アプリケーションで try-catch を書いてはいけません。

もう一度(ry、すみませんしつこいですね^^。でもこれ、めちゃめちゃ重要なのです。
https://docs.microsoft.com/en-us/archive/blogs/nakama/net-part-1


賛同するかどうかは別だけど
これがMS推奨の定跡
2020/06/09(火) 21:33:11.86ID:/5vAUGTr
かこいー
2020/06/09(火) 21:34:51.57ID:GiCu1zyF
>>181
嘘だよ
まず、アプリケーションをストップさせたくないときはcatchしないと駄目だよ

そもそもファイルがない程度で例外出しやがるお前（Microsoft）みたいなのがいるから足並みが揃わないんだろうが
そもそもみんな例外の扱いに困ってんのはお前（Microsoft）のせいだお前（Microsoft）の

それと例外自体が造り手の思想依存であって
飛んできた例外に例外であることの正当性の保証はない
みんながみんな好き勝手飛ばすし
正当な処理結果なのに例外としてcatchさせるような作り方もできる
こんな状況なので方針というのは作れなくて1つ1つのメソッドでどういう動作にするか考えなくてはならない
2020/06/09(火) 21:45:54.45ID:5mqVZkdG
>>180
キャッチしないとその場でクラッシュするから・・・
例えば、通信先の接続に失敗しただけで例外になるからこれでクラッシュするのは避けたいって時とか
そうすると色々教えてもらった結論としてはcatchしてから何もせず再スローするしかないと思ったんだよね

でもやっぱり気持ち良いものではないから代替案があればそっちにしたいけどいかんせん俺の知識が足りない
2020/06/09(火) 21:54:22.43ID:/rzxY16Z
>>183, 184
なんなんだよもう
脊髄反射でレスする前に一通り読めよ

リンク見つけられないのかもしれないからシリーズのURL貼っとくわ
https://docs.microsoft.com/en-us/archive/blogs/nakama/293
https://docs.microsoft.com/en-us/archive/blogs/nakama/net-part-1
https://docs.microsoft.com/en-us/archive/blogs/nakama/net-part-2
https://docs.microsoft.com/en-us/archive/blogs/nakama/net-part-3
https://docs.microsoft.com/en-us/archive/blogs/nakama/net-part-4
https://docs.microsoft.com/en-us/archive/blogs/nakama/netjava

>>153がリンク貼ってるAnders Hejlsbergも同じ考え方やで
2020/06/09(火) 22:22:59.33ID:5mqVZkdG
>>185
すまん、集約例外ハンドラが全然理解できてなかったから頓珍漢なこと言った
ちょっとちゃんと読ませてもらうわ
2020/06/09(火) 22:33:12.16ID:DuX3svuW
>>183
FileNotFoundExceptionが出て欲しくないなら
きちんと事前にファイルの存在を確認すれば良いだけだろ
2020/06/09(火) 23:22:54.12ID:hAic2KbQ
ファイルの存在確認してからファイルオープンの間までにファイルが消えることがあるんですが…
2020/06/09(火) 23:30:26.73ID:SzX0azwe
ライブラリ内、関数内でcatchして、ファイルが無かった旨の結果を返すか、
(必然的に、成功、失敗のいずれかと付随する結果を持つ結果オブジェクトを返すことになる)
もしくは誰もキャッチせずアプリケーションエラーにしてアプリごと落としてしまうのが良いんじゃないの？
要は、ファイルが無い場合ってのは、それをもってなにか処理したい場合、正常系の1パターンであって、無理に救う異常系ではないと思う。
2020/06/09(火) 23:46:24.77ID:JzXG4Km2
結局どの階層でもファイルが見つからない状況に興味がなければ
そのアプリは落ちるしかあるめえなあ
2020/06/10(水) 01:16:04.50ID:uuofLs7B
>>189
落とした方がいいかどうかなんて
そんなのお前が決める問題じゃないじゃん
2020/06/10(水) 01:30:48.32ID:uuofLs7B
作るメソッドが例外を飛ばしまくるくせに
ドキュメントを書かないなんて奴は最悪で完全に制御するためには
メソッドの中のソース読んで例外が今回の仕様にマッチするかどうかまで調べないといけない現実
ファイルがなかったから飛んだ例外なのかファイルを開いて編集できなかったから飛んだ例外なのか
造り手はそれに気を使う義理はないが
2020/06/10(水) 04:06:10.84ID:YByuqf7A
全部catchしてそのままthrowが基本。
2020/06/10(水) 08:41:52.94ID:5C8ycaaS
そのまま投げるならキャッチする必要ないけど？
2020/06/10(水) 09:04:43.18ID:K14nATts
>>194
catchしないとそこで止まる
2020/06/10(水) 12:25:52.43ID:5C8ycaaS
キャッチされなかった例外はそのまま上位へ伝播したとおもったが
2020/06/10(水) 12:43:33.19ID:Zx+vJVNc
>>196
それであっているしそうしないとthrowの意味が半減する
catchして何か処理したうえで再スローするのならともかくそのままthrowって言っている>>193とそこで止まるって言っている>>195は例外処理の基本すらわかっていない
2020/06/10(水) 12:44:04.48ID:QxZHo/84
いっぱいとらいきゃっち書いてそう
2020/06/10(水) 12:46:06.23ID:ZZdZ0hPp
多分Java屋崩れ
2020/06/10(水) 13:03:07.18ID:5C8ycaaS
>>199
検査例外の対応がそうするのが主流ってことか？
201デフォルトの名無しさん
垢版 |
2020/06/10(水) 13:08:48.62ID:YjHyIyr2
catchしてそのまま何もせず再スローはメンテを意識して書く場合はあっていいよw

// ここで○○が××の場合HogeExceptionが発生
とかコメントで書くよりよっぽどいい。
記憶力抜群の人はどうだか知らないけど、だいたい忘れちゃうんだよ。
どこでどんな例外が起こる可能性があるかなんて
202デフォルトの名無しさん
垢版 |
2020/06/10(水) 13:38:18.89ID:VsaDrFv7
何もしないで再throwにしても
イベントログに描き込んだり
ログファイルに出力したり
黙ってても出来ることはある
2020/06/10(水) 14:23:24.58ID:y/XlP2+v
>>201
再スローする時にthrow exp;とかやってるあほなJava屋上がりを見たことがある
2020/06/10(水) 14:26:03.03ID:PhLjERI1
try{
....
}
catch{
throw;
}
205デフォルトの名無しさん
垢版 |
2020/06/10(水) 15:06:38.37ID:5C8ycaaS
>>202
ログ出力してるのになにもしてないとか言うと話がかわるんだが
206デフォルトの名無しさん
垢版 |
2020/06/10(水) 15:08:51.68ID:5C8ycaaS
>>201
たしか標準のドキュメントコメントに例外あったはずだか、それより良いと？
2020/06/10(水) 15:10:25.22ID:ZZdZ0hPp
設定ファイルを触っておいて
何もしてないのに起動しなくなりました
って言う奴と同じだなぁ
2020/06/10(水) 15:16:17.31ID:uuofLs7B
iniファイルがよく壊れるソフトの開発者に限ってユーザのせいにするんだぜ
2020/06/10(水) 15:17:25.83ID:yPI+9HIl
例外処理のものっそい便利なライブラリとかないん？
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。