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

1 名前：名無C mailto:sage [2019/03/07(木) 06:35:41.12 ID:6L3KEJfe0.net] !extend:checked:vvvvv:1000:512 次スレを立てる時は↑を2行冒頭に書くこと（1行分は消えて表示されない為） 「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。 他のスレッドでは書き込めないような低レベルな質問、 質問者自身なんだか意味がよく分からない質問、 ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。 内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。 なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。 C#に関係の無い話題や荒らしの相手や罵倒レスはやめてください >>980を踏んだ人は新スレを建てて下さい。 >>980が無理な場合、話し合って新スレを建てる人を決めて下さい。 ■関連スレ C#, C♯, C＃相談室 Part93 mevius.5ch.net/test/read.cgi/tech/1492818720/ ■前スレ ふらっと C#,C♯,C＃（初心者用） Part141 mevius.5ch.net/test/read.cgi/tech/1544839627/ ■コードを貼る場合は↓を使いましょう。 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 referencesource.microsoft.com/ VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured 502 名前：デフォルトの名無しさん mailto:sage [2019/04/23(火) 19:36:05.31 ID:2vLu2U8QM.net] お前は勘違いしてる GUIとCUIで仕様が違ってる 503 名前：デフォルトの名無しさん mailto:sage [2019/04/23(火) 19:50:14.81 ID:2vLu2U8QM.net] await/asyncは単なるTask非同期処理を簡易的に書ける糖衣構文 次にawaitの次をどのスレッドになるかはその時の状態次第 GUIではそれでは困るのでデフォルトで同じスレッドが処理をするようにしてあるだけ 504 名前：デフォルトの名無しさん mailto:sage [2019/04/23(火) 20:19:35.25 ID:xFm0RmkHa.net] 訳のわからん勘違いをしてるのはどっちだよ 自信満々で馬鹿じゃないマジで 505 名前：デフォルトの名無しさん mailto:sage [2019/04/23(火) 20:30:14.95 ID:aIitEIPQ0.net] https://ufcpp.wordpress.com/2012/11/12/asyncawait%E3%81%A8%E5%90%8C%E6%99%82%E5%AE%9F%E8%A1%8C%E5%88%B6%E5%BE%A1/ 506 名前：デフォルトの名無しさん mailto:sage [2019/04/23(火) 20:30:27.32 ID:PlCSQgU2M.net] deligate 507 名前：デフォルトの名無しさん mailto:sage [2019/04/23(火) 20:36:54.48 ID:iDnak3xha.net] >>495 https://ideone.com/7wVOXT 508 名前：デフォルトの名無しさん mailto:sage [2019/04/23(火) 20:41:16.72 ID:xFm0RmkHa.net] 勘違いをしているのは俺の方だった... 申し訳ないですw 509 名前：デフォルトの名無しさん mailto:sage [2019/04/23(火) 21:04:08.70 ID:2vLu2U8QM.net] すなおでいいんでない？ 510 名前：デフォルトの名無しさん mailto:sage [2019/04/23(火) 21:19:00.48 ID:7omDh/oid.net] 煽る時点で目糞鼻糞 511 名前：デフォルトの名無しさん [2019/04/23(火) 21:57:22.24 ID:D0U8cwP90.net] 同じスレッドに戻ってきてもらうのに、簡単な方法ってないのかな・・・・ 512 名前：デフォルトの名無しさん mailto:sage [2019/04/23(火) 22:10:23.58 ID:iDnak3xha.net] >>505 >>490を見るに、コンソールアプリで特定スレッドで処理したいみたいだけど、どういった理由？ GUIなら、時間がかかる処理は別スレッドで、画面更新は絶対にUIスレッドで、といった使い分けがあるけど CUIで特定スレッドを意識する理由がちょっと思いつかないんだ 513 名前：デフォルトの名無しさん [2019/04/23(火) 22:42:29.23 ID:D0U8cwP90.net] >>506 WebAPIサーバを作りたく、その中で扱うデータについてトランザクション処理みたいなことをしたかったんです 通信関連でAwaitが多用されている中でも、データのロックをできるだけ減らしたい、またうっかりミスしてロック外に出ないでほしいと思ったんです 514 名前：デフォルトの名無しさん mailto:sage [2019/04/24(水) 00:21:10.86 ID:9Dlmymg8a.net] >>507 それを聞いても、「特定スレッドで絶対に処理したい」が主目標にはならない気がする 「ロックにReaderWriterLockSlimを使っていて、ロック取得と解放は同じスレッドで行う必要がある」のような状況ならまだ分かるんだけど もしもこの状況であるなら、SemaphoreSlimでロックするようにすれば、WaitOneAsyncで待つスレッドと、Releaseするスレッドを別にできる(=間でawaitできる) 万一本当に何か理由があって特定スレッドで処理を続けたいのなら、Taskをawaitするのでなく.Wait()で待つようにすれば、スレッドは切り替わらなくなる > うっかりミスしてロック外に出ないでほしい これが「ロックを取得したけど、解放を忘れる」ことを指すのであれば try {} finally {} や、ラップクラスを作ってIDisposable実装してusing() {} するのが対策になるかもしれない 取得と解放がメソッドを跨いだりするなら面倒くさくなるけど…… 515 名前：デフォルトの名無しさん mailto:sage [2019/04/25(木) 23:50:01.61 ID:1l/c830P0.net] https://ideone.com/TM1zJh if (ob.volume == volume)この部分なのですが 左辺は引数で取ったobのメンバ変数であることは分かるのですが右辺はどのメンバ変数なんでしょうか？ 入門書のコードなのですが… 516 名前：デフォルトの名無しさん [2019/04/25(木) 23:52:47.61 ID:LJHMbymK0.net] >>509 6行目 517 名前：デフォルトの名無しさん mailto:sage [2019/04/25(木) 23:54:19.01 ID:LJHMbymK0.net] いや、thisって答えた方が良いのか 518 名前：デフォルトの名無しさん mailto:sage [2019/04/25(木) 23:59:26.79 ID:8Sf9N2Ww0.net] 19行目にも同じ構造があるけどそっちはすんなり入ったんだろうか 519 名前：デフォルトの名無しさん mailto:sage [2019/04/26(金) 00:01:25.44 ID:6Aa9jI4a0.net] >>510 メソッドを呼び出したob1のメンバってことですかね？ 理解できました。ありがとうございます 520 名前：デフォルトの名無しさん mailto:sage [2019/04/26(金) 23:30:08.64 ID:9lAtl2Yi0.net] コンストラクタ内で例外をthrowするのはご法度ですか？ 521 名前：デフォルトの名無しさん mailto:sage [2019/04/26(金) 23:43:18.42 ID:p/I2x8fjd.net] >>514 定石ですよ [] [ここ壊れてます] 523 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 00:06:35.36 ID:Ern7/KCha.net] >>514 ご法度ではないし、むしろインスタンスを正しく構築できないなら積極的にthrowしてほしい 例えばStreamReader(String)の場合、ArgumentException系列から FileNotFoundExceptionやDirectoryNotFoundExceptionのIOException系列までthrowする 524 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 00:38:42.27 ID:yEc5G7yUM.net] 悪いとは言わないけど、最近はあまりコンストラクタで例外投げるような処理やらなくなったなあ 何故かと考えたら、async/awaitのせいだと気付いた コンストラクタではawaitできないから、昔みたいにコンストラクタでファイル読んだりするのはほぼ無くなった 525 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 00:45:53.35 ID:k66IsG4/a.net] あとDIと相性が悪い DI使ってると、コンストラクタで例外投げたらそもそもアプリが起動しない 526 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 02:44:50.91 ID:ni4YCIMc0.net] ドキュメントもコンストラクタで投げる可能性のある例外一覧が必要になるけど 実際あげきれなくて手薄になりがち そうなると設計できない 例外の種類でその後の動作をハンドリングしたいときに動かしてみて キャッチの種類を分けるしかない 仕様書に書いてあるこのエラー出せないんすけど？ このときの例外増やしてもらえます？ →入れた引数から判断できるでしょ？とかキチガイかよって 527 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 02:55:41.53 ID:TtZ/uEZc0.net] >>519 例外の種類を完全に把握できないのはコンストラクタに限ったことではないだろ 528 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 03:07:26.16 ID:ni4YCIMc0.net] >>520 そもそも例外嫌いなんよ俺 ビジネスロジックだとほぼ全部把握しないといけないのに 丸っと渡されると困るだけじゃん 529 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 03:45:53.67 ID:TtZ/uEZc0.net] その例外を全部把握しなきゃいけないというのがアホな考えなんだよ 予期できないのはExeceptionとしてまとめてキャッチして処理しとけばなんの問題もないね 530 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 06:32:15.89 ID:QhVWSAZD0.net] どっちも乱暴だな 531 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 07:35:46.92 ID:3SWE0tmA0.net] 例外は握りつぶすのが定石 532 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 08:12:46.03 ID:PiMoxWjk0.net] >>522 設計書になんて書くん？ 俺んとこ例外使うなら設計書に書いてない例外出しちゃうと大変なんだよ MSのドキュメントも全部はねーし マジ厄介 でもお客の言い分もわかる気がするんだよね 流石に何が来るかわかりませんってのはどうなの？ って思う 533 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 08:15:07.62 ID:PiMoxWjk0.net] >>522 ああ、だから例外返さないよねそれ 534 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 08:34:22.02 ID:9yG2LI1yd.net] 例外の発生要因なんてあらゆるものがあるんだから全部明示しろというお客の主張が不条理 設計書に例外全部明示しろとか要求されたことないね 535 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 08:51:37.56 ID:yNGf8etVa.net] 規約が足かせになってる場合は無視したほうがいい スキル低い人が大昔に作った規約かもしれないし 例外は復旧可能かつ復旧したいものだけキャッチして対処 それ以外はアスペクトでまとめて処理すればいいよ 536 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 09:11:45.63 ID:ibduGkrL0.net] コンストラクタで例外がってC+出身者みたいだな 537 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 09:25:13.44 ID:YyIkYDM+0.net] >>529 .NET Frameworkクラスもコンストラクタで例外投げるのに？ 538 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 09:26:49.68 ID:k66IsG4/a.net] >>529 C++のその説は迷信だけど、C#では事実としてawaitができないという重大な制約があるからなあ コンストラクタで例外を投げてはいけないわけではないが、そもそも例外を投げる可能性のあるような処理をコンストラクタでやらせることができるケースが少ないのは間違いない 539 名前：531 mailto:sage [2019/04/27(土) 09:33:56.80 ID:k66IsG4/a.net] もちろん、ArgumentNullExceptionのようにバグを検出してアプリを落とすことを目的とする例外は別だよ そういうのを除けば、例外を投げうる処理ってのはだいたいIOを含んでいてawaitが必要になるケースが多い 540 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 09:36:37.55 ID:yyWoHVeQa.net] いまだにオブジェクト倶楽部のをベースにしたC#コーディング規約なのかな 10年くらい前の時点でも悪評ぷんぷんだったのにどれだけ時代遅れなことしてるんだ コーディング規約作ってる奴のスキルが低い／古すぎ／多言語の知識しか持ち合わせてなくて クソな規約になってることはよくある コンストラクタで例外吐くのが望ましくないのはC++の話であってC#ではそんなこと全然ない 例外すべて列挙しなきゃいけないのはJavaの話であってC#にもそれを持ち込むのはナンセンス でも大抵規約のクソさ加減と規約作成者・組織の老害度は比例するんだよな 指摘しても直ることはないだろうから「これはクソなコードだ」と自覚を持ったうえで 規約通りのコードを書くしかない 541 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 11:46:22.17 ID:V1c8eqNrM.net] >>527 それって制御できないって言ってるんだよね？ その時はtry catchで握り潰せばいいんだけど 君はどうなればいいと思ってるの？ ある日例外が起きてアプリが止まっちゃってもそれは時代の流れでしょうがないと思ってるってこと？ 542 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 12:00:49.48 ID:ASguEO4td.net] >>534 予期せぬ例外が起きたら発生箇所のスタックトレースを表示させてバグ修正に役立てるよ 客もその画面キャプチャを送ってくれる Execeptionにはそういうデバッグに役立つ情報入ってるからマジ便利だわ 543 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 12:01:52.85 ID:reMuF7mTd.net] >>535 客にスタックトレース見せちゃだめw 544 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 12:22:00.72 ID:yNGf8etVa.net] コンストラクタで例外を出すのが妥当なら出すべきだ しかし、例外を出すような責務は得てしてファクトリやリポジトリなど外部のクラスが担うことが多い傾向にある なので正確に言うと、オブジェクトの生成という責務を分離してない汚いプログラムはダメだ、なんだけど それが誤って拡散した結果、コンストラクタで例外を出すプログラムはダメだ、に拡大解釈されてしまったのだろう // コレは生成責務が分離されてないからダメだ class Hoge { public Hoge(int id) { var dto = DB.FindHoge(id); // 例外なげる m_id = id; m_name = dto.name; } // コレは責務が分離されてるからOK class HogeRepository { public Hoge Find(int id) { var dto = m_db.FindHoge(id); // 例外なげる return new Hoge(id, dto.name); // 実装次第で投げたり投げなかったり } // コレもOK 例外投げるが責務としては妥当 class Hoge { public Hoge(int id, string name) { if (id < 0) throw new BadHogeFormat("id"); if (UTIL.NotMatch(@"^H\d{8}$", name)) throw new BadHogeFormat("name"); m_id = id; m_name = name; } 545 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 13:20:27.71 ID:rUmkpmPg0.net] >>533 > コンストラクタで例外吐くのが望ましくないのはC++の話であって そんな話は聞いたことないが？ 546 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 13:38:48.88 ID:ibduGkrL0.net] C+の話は C+のコンストラクタとデストラクタの言語仕様をよく理解してない奴の誤解だから もともと正しくない 547 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 13:43:38.03 ID:bs+zTlgP0.net] >>539 お前はさっきから何の言語の話をしているんだ？ 548 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 13:45:42.92 ID:ibduGkrL0.net] 話しかけるなゴミが 549 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 13:46:18.87 ID:vrUpwJdGa.net] ダメも糞も引数が不適切なら例外投げるしかないねそもそもw もちろん（注意喚起とか）何らかの意図を持ってあえてコンストラクタではなく ファクトリーメソッドやTryCreateXxxxにする方法もあるけど、 少なくとも誰が考えても引数が不適切なら例外発生が予見できるなら コンストラクタで例外投げて何も問題ない 550 名前：デフォルトの名無しさん [2019/04/27(土) 16:53:30.48 ID:hssASZhyF.net] デストラクタで例外吐くのはあり？ 551 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 16:57:52.36 ID:krlg75LI0.net] どこならokとかngとかじゃなくて例外が発生したなら吐かなきゃ駄目 例外の前提を変えちゃ駄目 552 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 19:59:50.65 ID:UyCSNWt+M.net] >>543 基本的になし デストラクタの意味がなくなるから 553 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 20:00:47.02 ID:rUmkpmPg0.net] >>543 なし 554 名前：デフォルトの名無しさん [2019/04/27(土) 20:39:48.83 ID:ucBEJWSU0.net] デストラクタって解放し忘れたアンマネージドリソースの解放をするためにある奴でしょ？ ただそれだけの処理に例外とか要る？ 555 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 20:43:57.48 ID:xE/0VH9u0.net] >>547 どんな想定かわからないし入れたい人は入れればいいんじゃないの 556 名前：デフォルトの名無しさん [2019/04/27(土) 21:09:36.81 ID:ucBEJWSU0.net] C#のデストラクタは実行タイミングが不明な上に 他でキャッチできないからそのままクラッシュする事になるが それが目的なら 557 名前：デフォルトの名無しさん mailto:sage [2019/04/27(土) 22:32:08.58 ID:krlg75LI0.net] デストラクタであろうと例外が発生したなら吐くべき デストラクタで例外なら大体最終的にアプリ落とす結果になるだろうけど 普通に設計すりゃまずデストラクタで例外が必要にはならんとは思うが 558 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 07:43:44.94 ID:Rwl5KJzI0.net] そりゃどこでも例外が出りゃ吐くべきだろ。デストラクタで出た例外は握りつぶせとでもいうのかよ 559 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 08:59:56.68 ID:vQlivpSSa.net] デストラクタの例外は運用に入ったらログ吐いて握り潰すしかない 開発中にどれだけ発見しきれるかが勝負 560 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 09:42:23.56 ID:3t4t6vYZM.net] 馬鹿しかいないのかな デストラクタで例外をキャッチすべきかじゃなくて デストラクタで例外を投げるべきかだろ 561 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 09:48:33.86 ID:3t4t6vYZM.net] どうみても例外をデストラクタで握りつぶすなんて話はしてない デストラクタで挙動がおかしな場合そこから自前で例外を投げるかどうかだろ どうしてこんな前提すらわからないのか？ 562 名前：デフォルトの名無しさん [2019/04/28(日) 10:20:38.37 ID:ddGaHMPJ0.net] デストラクタで例外投げるのは出来るけど デストラクタの呼び出し元はファイナライザースレッドになる故 デストラクタ以外の場所でキャッチして ログ記録したりは出来ないが、よろしいか？ 563 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 10:52:59.00 ID:F7dfQde00.net] ところで、C#ってコンストラクタで例外吐いたとき、インスタンスは生成されて戻されるの？ そのインスタンスのデストラクタは（実装してればどこかで）実行されるの？ 564 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 14:01:09.54 ID:Cfig35XD0.net] >>554 お前黙ってろよ… > デストラクタで挙動がおかしな場合そこから自前で例外を投げるかどうかだろ そんな話は>>545-546で既に終わってる 今の話は例えばデストラクタでファイルクローズした時そのメソッドで例外送出されたらどうするかって話な > どうしてこんな前提すらわからないのか？ わかってないのはお前だけ 565 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 14:02:16.88 ID:Cfig35XD0.net] >>556 > ところで、C#ってコンストラクタで例外吐いたとき、インスタンスは生成されて戻されるの？ されない > そのインスタンスのデストラクタは（実装してればどこかで）実行されるの？ されない 566 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 14:33:26.09 ID:18CJ+0uF0.net] ファイルクローズなんてデストラクタの仕事じゃないからクラス設計が間違ってる もしそうせざるを得ない理由があるならアプリ終了するだけ アプリ終了されて困るなら正しくクラス設計すればいい 567 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 15:52:04.90 ID:QPV4rne2d.net] >>559 例えばの話してんだからそこに文句付けるのはお門違い 568 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 17:06:19.94 ID:lUhOqb6w ] [ここ壊れてます] 569 名前：d.net mailto: >>560 例えだろうがなんだろうが結論は同じ [] [ここ壊れてます] 570 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 17:07:43.10 ID:3i1J1gafM.net] 年甲斐もなく疲れた お前らこんな所で何をやってんだ青瓢箪か？ 571 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 17:32:00.19 ID:+oA/oQuO0.net] ここでは例外の話でドンパチ よくのぞいてるVBAスレでもOn Errorの話でドンパチ どちらを見てるのかわからなくなってくる 572 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 17:38:04.38 ID:Cfig35XD0.net] >>559 > アプリ終了されて困るなら正しくクラス設計すればいい 具体的に書けないなら黙ってろってw 573 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 18:13:29.08 ID:KKCCRPTWa.net] デストラクタの中でファイル操作やクローズするのは間違ってるな そこで例外でたらどうしようもない ログ取るのも同じ 574 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 18:25:38.64 ID:kK/njqra0.net] メンバ変数を仕様上どうしてもDBから引っ張ってくるデータで初期化するしかなく、 コンストラクタ内でDB処理異常時に例外を吐く処理があります。 この場合コンストラクタ内では何もせず、インスタンス生成後にInit()のようなメソッドを 呼び出してもらうほうが使う側は楽でしょうか？ 575 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 18:31:50.14 ID:uWFo9H7Wa.net] そもそもC#でデストラクタに処理を書くこと自体が基本ありえないと思うんだけど・・・ リソースの解放なら（まともな構造のソースであれば）Dispose時に済ませるだろうし デストラクタにわざわざ処理を書いて、しかもその処理が例外を引き起こすパターンって 具体的にどんなのがありうるんだ？ 576 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 18:32:37.29 ID:lUhOqb6wd.net] >>566 コンストラクタで例外を吐いてください。 577 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 18:34:32.85 ID:lUhOqb6wd.net] >>564 ぜひ具体的に例示していただきたい。 578 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 18:39:48.98 ID:e0sCdFMHa.net] >>566 Init()を呼び忘れて使うリスクが出てくるので、インスタンス生成時に済ませたい派 ただDB関連では >>531-532 が言うように非同期処理をしたいだろうから 「コンストラクタはprivateにして、public staticなasyncファクトリを提供」が良いと思う インスタンス生成時に例外出る場合だと変数の宣言と初期化が分離するけど、C#だと初期化し忘れはエラーになるから許容範囲じゃないかな Foo foo; try { foo = CreateFoo(); } catch(BarException) { 何か復帰処理 } // 以下fooを使った処理 579 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 18:45:37.21 ID:3i1J1gafM.net] 器が小さい奴はすぐ引っ込みが着かなくなるから困ったものだ 580 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 18:46:32.36 ID:Cfig35XD0.net] >>569 MSがデストラクタからDispose呼んでるんだがw // Free any unmanaged objects here. で例外が発生するケースをどう扱うのか具体的に添削してやってくれ https://docs.microsoft.com/ja-jp/dotnet/standard/garbage-collection/implementing-dispose 581 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 18:47:40.42 ID:vQlivpSSa.net] >>566 >>537の考え方が正解 そういう時はファクトリーを使うという考え方が世界標準 582 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 18:56:32.95 ID:lUhOqb6wd.net] >>572 どう扱うも何もアプリ終了させろってだけだが？ ハンドリングすべきではないものをどうこうしよとしないで 583 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:02:39.46 ID:kMBz0MBMa.net] >>566 上にも書いたけど、あえてコンストラクタではなくstaticなTryCreateHogeみたいなのだけ提供して 注意喚起する方法もあると思うよ >>567 デストラクタの存在理由はClose/Disposeを忘れた場合のフェイルセーフなんで アンマネージドな共有リソースを占有するオブジェクトの場合はほぼ必須だし、 例外を投げるかどうかはともかく、デストラクタの中で例外的な事態が 発生することも普通にありえるとは思う。（例えばデバイスのクローズに失敗） 584 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:02:50.34 ID:lUhOqb6wd.net] どんなに丁寧に処理したって完全に例外を対応するなんてことは不可能 599の最後でちゃんとやれば良いokみたいに書いちゃったのが良くなかった ちゃんとやったって無理なことはある 585 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:06:45.39 ID:KKCCRPTWa.net] >>575 その使い方はダメだと思うけど… 586 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:09:47.55 ID:lUhOqb6wd.net] >>576 599じゃなくて559でした 587 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:10:36.56 ID:kMBz0MBMa.net] >>577 何がダメ？ フェイルセーフって意味分かりますか？ 588 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:17:31.79 ID:KKCCRPTWa.net] 無関係だけど一応答えるよ フェイルセーフって言うのは失敗しても安全な状態に落ち着くこと 例えば信号が壊れても青信号になるんじゃなくて赤信号になるような設計 ファイルクローズは別にフェイルセーフの概念と関係ない tryのfinallyはフェイルセーフじゃないよ 589 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:20:35.61 ID:Cfig35XD0.net] >>574 ああ、お前じゃ無理だったな、すまんw > アプリ終了されて困るなら正しくクラス設計すればいい とほざいてた>>559、出てこいやー 590 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:22:21.81 ID:fIrxxOza0.net] >>572 よく読め 591 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:22:22.23 ID:JJw12cyBa.net] リソースのライフタイムの管理とリソースを使用して何かする責務を別の責務として分離したほうがいい リソースの取得だけを分離する場合はファクトリーパターンが使われる ただしこの場合はリソースを閉じる責務とリソースを使用する責務が同じクラスに混在してしまう 結果としてデストラクタでの例外といった問題が連鎖して発生する これに対応するためにはファクトリーアイソレーションパターンを使う このパターンならリソースのライフタイム管理とリソースの使用を完全に分離できる コンストラクタでもデストラクタでもリソースの開閉に由来する例外は発生しなくなる 592 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:23:12.72 ID:KKCCRPTWa.net] デストラクタでたとえば解放忘れの大きなメモリを開放するとしても その前に他で大きなメモリを確保しようとすると死ぬ デストラクタでファイルのクローズ忘れをクローズしようとしても その前に他でファイルを開こうとするとエラーになる デストラクタでいろいろ開放しても何も助けてない 役に立ったとしても偶然であって実質はバグを握りつぶしてるだけ 593 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:25:35.89 ID:KKCCRPTWa.net] 今までアンカー売ってないけど>>579向け デストラクタで何か開放してもバグの温床になるだけ 594 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:26:43.51 ID:kMBz0MBMa.net] >>580 関係あるからw 同じことをくどくど書くのは嫌いだが、デストラクタの存在理由は コードの利用者がClose/Disposeを呼び忘れる、というヒューマンエラーに対するフェイルセーフ。 これは議論の余地はないよ 595 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:26:58.59 ID:KKCCRPTWa.net] みんなフェイルセーフって言葉を使うけど大体意味間違ってる 596 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:28:16.75 ID:uWFo9H7Wa.net] ああ、Dispose呼び出し忘れ対策のデストラクタか それなら、自分の場合は ・デストラクタには「Dispose(false)」以外書かない（trycatchもしない） ・Dispose()側が例外を投げるかどうかは解放するリソース次第 ・デストラクタの中に延々とリソース解放処理なりtry-catchが必要な処理なりを書いてるのだとすれば 　そのソースコードは根本的におかしい 597 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:30:31.27 ID:kMBz0MBMa.net] >>585 だから、デストラクタ「で」積極的にClose処理をするんじゃないの。 Close処理は普通にDispose/Closeに書くに決まっているわけだが、 使用者がそれを呼び忘れても最悪GCのお片付けのタイミングで Close処理が行われるようにするための仕組みがデストラクタ 598 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:32:19.82 ID:uWFo9H7Wa.net] ごめんもいっこ ・IDisposableなオブジェクトをDisposeせず使用している時点で実装不備とみなしてよい （フィールド変数だったらポカミスで解放し忘れはあるかもしれないけど、 　少なくともローカル変数ならusingを意図的に使ってない時点でコーダーが悪意を持ってると判断する） 599 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:32:33.80 ID:KKCCRPTWa.net] >>586 いつまで勘違いしてるのか？ フールプルーフとフェイルセーフは別物だからｗｗｗ 600 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:35:22.92 ID:JJw12cyBa.net] >>590 DIに管理させるからusingもDisposeもしないという構成は非常に多い 601 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:35:29.40 ID:KKCCRPTWa.net] 自分の使ってるコードで完結してるのにデストラクタでアンマネージなどのリソースを 開放するのは間違った使い方 いくら自信たっぷりに書いてるのか知らないけど間違ってる 602 名前：デフォルトの名無しさん mailto:sage [2019/04/28(日) 19:44:53.23 ID:JJw12cyBa.net] >>593 知らない他人が何年後かに使うかもしれない だとしたら誤った使われ方でも最低限の安全性を確保できるように作るべき デストラクタでリソースを解放するのはアリ

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef