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

**ななC** ◆jPpg5.obl6 · 2020/05/27(水) 10:14:39.92

■前スレ
ふらっと 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/03(水) 22:58:52.61

c++
java
javascript

これらは業務の人が使ってて田舎でも求人がある
あとVB6　python　意外なことにperlとか
何に使ってるのかは知らない

**デフォルトの名無しさん** · 2020/06/04(木) 01:31:22.32

>>78
自分はMS Officeとの親和性の高さからC#(というかMicrosoftの開発環境)を使っている。
　結局ユーザーが使うのはWindows10上でWord、Excelであり、それのドキュメントを食って処理が始まる以上、OSSの中途半端なライブラリには頼れない。

**デフォルトの名無しさん** · 2020/06/04(木) 02:18:15.36

>>78
OSSのライブラリが充実してない？具体的に比較してみて

**デフォルトの名無しさん** · 2020/06/04(木) 09:22:46.32

>>79
VB6は過去のレガシー案件だろ

**デフォルトの名無しさん** · 2020/06/04(木) 10:03:16.26

OSSが充実してないのは何となくわかる
中途半端に開発止まってて全機能網羅してないC#ラッパーとか結構見かける

**デフォルトの名無しさん** · 2020/06/04(木) 10:27:08.63

C#erを名乗るおれですら最近はPython使ってるもんね
機械学習系のことやるならPythonになっちゃうんだよなあ

**デフォルトの名無しさん** · 2020/06/04(木) 10:39:43.53

C#というよりはWindowsの問題だと思うなあ
俺もC#でプログラミング覚えて仕事でも一番よく使うのはC#だったけど、Web系に行ってからはWindowsの壁を感じるようになって、今では全く使ってないわ
C#な人って出来合いのものを活用するという考え方が薄くて、わりと自分でコード書いてなんでも解決しようとする人が多いように思う

**デフォルトの名無しさん** · 2020/06/04(木) 10:58:46.85

携わる分野が変われば言語も変わるという普遍的な話なだけでは

**デフォルトの名無しさん** · 2020/06/04(木) 11:31:40.46

Pythonはライブラリを組み合わせるだけだからつまらないのがな

**デフォルトの名無しさん** · 2020/06/04(木) 11:32:53.20

DropboxはPythonの負債に四苦八苦してるよね

**デフォルトの名無しさん** · 2020/06/04(木) 16:35:14.44

NuGet使ったら「訳のわからんもん使うな」と上司と喧嘩になった

**デフォルトの名無しさん** · 2020/06/04(木) 16:53:36.43

訳のわからんライブラリを使うなってのならわかるけど、NuGet自体を使うなってのはキチガイ

**デフォルトの名無しさん** · 2020/06/04(木) 16:53:57.22

そこでPacketですよ

**デフォルトの名無しさん** · 2020/06/04(木) 17:10:37.74

NuGetで持ってくるライブラリ次第だな
MSや大手メーカーならそれなりに信頼出来るけども、
個人で作ってるライブラリは実用例が無いと信頼出来ないし
あとライセンス

**デフォルトの名無しさん** · 2020/06/04(木) 18:05:56.12

linux屋がいないとossは発展しづらい
linuxのc#は比較的最近になるから

**デフォルトの名無しさん** · 2020/06/04(木) 18:16:05.25

CUIで作るとして何が欲しい？

**デフォルトの名無しさん** · 2020/06/04(木) 18:18:03.10

C#で作るのにCUIとかゴミ

**デフォルトの名無しさん** · 2020/06/04(木) 19:05:50.14

じゃPowerShellはゴミだね

**デフォルトの名無しさん** · 2020/06/04(木) 19:08:35.14

荒らしはスルーで

**デフォルトの名無しさん** · 2020/06/04(木) 19:12:40.45

かまってちゃんもスルーで

**デフォルトの名無しさん** · 2020/06/04(木) 19:40:14.14

>>85
わかる。車輪再開発ばかりだわ

**デフォルトの名無しさん** · 2020/06/04(木) 20:06:13.33

Windowsは伝統的にCUI環境が貧弱で、UNIXのように既製の小さなコマンドをちょこちょこっと組み合わせてやっちゃうという風にはいかないことが多かった
しかもクライアントアプリの開発が多く、システムに入っているコマンドに頼ると環境に依存しやすいために忌避されやすい
結果として、インプロセスのコーディングに頼る文化ができたんだろうね
必然的に細かい要件がコードに入り込みやすく、OSSにできるような汎用的なものが生まれにくい

**デフォルトの名無しさん** · 2020/06/04(木) 20:09:24.15

なぜ最後の文の結論になったw

**デフォルトの名無しさん** · 2020/06/04(木) 20:24:38.50

OWINがあるから、CUIでもweb i/fは作れるから
と思ったんだけどね

**デフォルトの名無しさん** · 2020/06/04(木) 21:28:55.14

>>94
dockerでフィクスチャ作るような奴欲しい

**デフォルトの名無しさん** · 2020/06/05(金) 18:07:08.06

WindowsではOSSが少ないのではなく、64ビットのWindows7が浸透してきたころから
OSSが減ってきているって感じじゃないかな

Win7 64はアプリでもなんでも署名が必要で、特にドライバは署名が正しく行われて
いないと嫌がらせのような開発者モードでしかシステムが動かない
署名が悪いとは思わないけど、署名を取得するには個人の開発者ではまかなうのが
大変なレベルのお金がかかるし、ドライバ作れないのであれば古い機器を有効活用
したりアイデア機器とかも作れないしでOSS作ってくれる層からみるとつまらない

Androidもユーザが自由にやれていたころはOSSが多かったけど、どんどん変な縛りが
増えてPlayに怪しげなS/Wは増えたけどOSSのプロジェクトはどんどん減っている

ちょっとしたアプリなら今でも作れるよねっていうのは分かるけど、大型のOSS
プロジェクトをやってくれる人は、意味のない縛りの多いプラットフォームではやってて
面白くないからWindowsのOSSをどんどんやめていってるんじゃないかな

**デフォルトの名無しさん** · 2020/06/05(金) 18:17:13.81

妄想おつ

**デフォルトの名無しさん** · 2020/06/05(金) 20:09:48.86

Microsoft自体がOSS推してるのを知らないのか？

**デフォルトの名無しさん** · 2020/06/05(金) 20:18:30.44

開発リソース割けなくなった製品の姥捨山として考えてるイメージ

**デフォルトの名無しさん** · 2020/06/05(金) 20:27:24.53

>>107
現実を見なさい

**デフォルトの名無しさん** · 2020/06/05(金) 21:58:19.72

質問だけど
Windowsアプリ作るにあたり
VisualBasicを使っちゃいけなくて(好まれなくて)C#を使うべきっていうのは
どういう理由からですっけ？

**デフォルトの名無しさん** · 2020/06/05(金) 22:07:18.81

>>109
古いからって理由だと思う

**デフォルトの名無しさん** · 2020/06/05(金) 22:13:26.64

でもマイクロソフトも新規機能は付けないって言ったり
vbオワコン感あるね
今からやるのは絶対避けた方がいいな

**デフォルトの名無しさん** · 2020/06/05(金) 22:35:39.50

そうざますかなるほど

**デフォルトの名無しさん** · 2020/06/06(土) 23:27:10.97

>>109
オブジェクト指向言語に寄せていくとC#とかJavaみたいなシンタックスになっていくって聞いたことある。VBみたいな書き方は向いてないんだって。

**デフォルトの名無しさん** · 2020/06/07(日) 11:35:44.28

自分をオブジェクト指向だと思い込んでる手続き型言語のイメージ
クラス定義をしてるというよりも、クラス定義をする命令を書いてる感じがする
End句とか特に

**デフォルトの名無しさん** · 2020/06/07(日) 11:36:39.69

ごめん
意味不明な事書いた

忘れて

**デフォルトの名無しさん** · 2020/06/07(日) 12:01:10.67

>>113
なるほどVBはオブジェクト指向に対応してないと。
これですっきり理解できました。

**デフォルトの名無しさん** · 2020/06/07(日) 12:07:01.26

>>116
納得しちゃダメw

**デフォルトの名無しさん** · 2020/06/07(日) 13:34:29.22

誰得

**デフォルトの名無しさん** · 2020/06/07(日) 13:38:21.36

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.81

ネイティブアプリを作ってるのですが、
パスワードがかけられたファイルをオープンしたりしようとしています。
コンパイルされるからパスワードはコードにリテラルで書こうと思っています。
が、
c#のコンパイル物の逆コンパイル性はかなり容易なのでしょうか？
Javaはコンパイルしても逆コンパイルで全部戻せれるそうですが。

**デフォルトの名無しさん** · 2020/06/07(日) 15:26:10.81

>>120
C#の逆コンパイルはフリーウェアでほぼ完全にできるレベル

**デフォルトの名無しさん** · 2020/06/07(日) 15:26:15.58

>>120
一瞬で逆コンパイルできるから、ソースにパスワード埋め込んだ状態で配布するとか論外

**デフォルトの名無しさん** · 2020/06/07(日) 15:27:26.51

>>120
てかVisual Studio使ってるなら簡単に逆コンパイルできるの知ってるやろ？omnisharpですら最近できるようになったし、昔からilspy等はよく使われてる

**デフォルトの名無しさん** · 2020/06/07(日) 15:45:43.26

パスワード判定アプリだけc++で書いてc#からキックするって手もある
わかるやつにはわかっちゃうけど

**デフォルトの名無しさん** · 2020/06/07(日) 15:48:05.93

>>120
クライアントに配布する時点で秘匿は無理だと思え

**デフォルトの名無しさん** · 2020/06/07(日) 15:50:18.31

ここもVBA質問スレのレベルかね

**デフォルトの名無しさん** · 2020/06/07(日) 16:56:57.78

そもそもネイティブアプリって何さ？

**デフォルトの名無しさん** · 2020/06/07(日) 16:59:43.95

>>127
Webアプリに対してクライアント側だけで動作するアプリ、って意味合いでネイティブって言ってるんだろな

**デフォルトの名無しさん** · 2020/06/07(日) 17:00:17.90

>>126
重複の上テンプレさえ不完全にされた失敗スレに何を期待しているの？
>>127のようにグーグル検索すら使えない人が来るのに

**デフォルトの名無しさん** · 2020/06/07(日) 17:11:15.20

パスを見られたくないのなら認証されたユーザーからの要求があった場合にはサバ側でパス保護ファイルを開いてそのバイナリをネットで送るって形にするしかないな

**デフォルトの名無しさん** · 2020/06/07(日) 22:07:54.57

そんな糞めんどくさいことしなくてもインストール時か初回起動時に
ユーザーにパスワード（っていうか復号コードだと思うけど）を入力してもらえばいいでしょw

**デフォルトの名無しさん** · 2020/06/07(日) 23:42:30.31

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.58

例外って一度考え始めちゃうとめっちゃ難しいな
色んなサイトのコードとか見てると例外を乱用してるようにしか見えないものが多いように感じる(特にネットワーク関連)
だからといってどこを例外にすれば正しいコードになるのか全然わからん
やっぱり例外処理は全く使わないで済むようにくらいの勢いで想定される例外を自力で検出するのが一番良いんだろうか

**デフォルトの名無しさん** · 2020/06/08(月) 07:36:06.86

>>133
なんか基準があるはずよ
落ちるのだけはやめてって言われてるなら
GUIの操作するメソッド全部でcatchしてメッセージでも出さんといかんじゃん
それとも「ああ、死んじゃっていいよ」って言われるかもしれんし
この場合は何もしないし
「ログにだけ出して」
ってのもあるし

そもそも各クラス例外を出す方針に一貫性がない
開こうと思ったファイルが開けないときの動作は普通は例外にしたくないけど例外が飛んでしまうときはcatchしないといけないわけで
まあ、個別に対処が必要？

**デフォルトの名無しさん** · 2020/06/08(月) 07:41:47.96

Rubyの話をする奴は、ちょっと話が違うとか理解することはできんのかな。

**デフォルトの名無しさん** · 2020/06/08(月) 07:45:18.91

>>133
例外は、Catchしたとて復帰不可能なものはアプリケーションエラーにして落とすのに使ってるかな。
そのメソッド内で完結できるならばCatchするというか。
後始末してから結局throwするケースもあるけど。

上っ面がアプリケーションからバッチ処理に変わっても同じように使える事、ぐらいを想定して例外処理書くと統一感出ると思うよ。

**デフォルトの名無しさん** · 2020/06/08(月) 09:12:40.55

>>134
自作だからその辺りの基準はないなあ
とはいえ世間でも基準は割とバラバラなのか
今回作ってるのはネットワーク関連のクラスなんだけど、初めて手を出す分野だからどれが個別に対処できるかは正直よくわかってないんだよね
参考にしてる資料に忠実に作ったら、ちゃんと動くんだけど例外処理だらけなのが見ててすごく気持ち悪くて、これで本当に正しいのかわからなくなったというか

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

例外は普段最低限しか使用しないものだからイメージできなかったけど二人のお陰でなんとなく輪郭が見えてきた気がする、ありがとう

**デフォルトの名無しさん** · 2020/06/08(月) 11:34:14.50

例外は１つ残らず握りつぶせ

**デフォルトの名無しさん** · 2020/06/08(月) 12:23:59.18

>>137
例外って究極のgotoだからね。
その場でやっつけないなら慎重に受ける場所とその後の動きを検討しないといかんよ。
毎回その場でやっつけて、エラーとして呼び出し元に帰すって方針ならそれはそれでいいかも知れんけど、
誰かキャッチするだろって方針で、続行不能だからと適当に例外吐いて落とさせてると、あとで困る。特にバッチ処理。

**デフォルトの名無しさん** · 2020/06/08(月) 13:24:22.92

https://ufcpp.net/study/csharp/misc_exception.html

**デフォルトの名無しさん** · 2020/06/08(月) 14:31:54.71

>>135
そいつはこの板のあちこちに出没する有名な荒しだからスルー推奨。
いくら指摘しても自分に都合のいい話しか目に入らないから相手するだけ無駄で、スレを汚すことになる。

**デフォルトの名無しさん** · 2020/06/08(月) 14:45:08.81

>>133
エラーハンドリングの基本的な考え方はこのシリーズ読むと良いと思う
https://docs.microsoft.com/en-us/archive/blogs/nakama/293

**デフォルトの名無しさん** · 2020/06/08(月) 21:31:29.92

>>138
これはネタで書いたんだろうけど、例外は適切な場所で握りつぶすのが大事だよな。
「知ってる例外はcatchするけどあとはスルー」ってのが最悪。

**デフォルトの名無しさん** · 2020/06/09(火) 05:12:12.64

色々資料をご紹介いただきありがとうございます
つまり、例外が大好きな.NETを呪いながら潰せる例外はメソッド内で潰し、潰せなければどのような例外があったかをきちんと調べられるようにすれば良いわけかな
今回は例外が発生してもクラッシュせず、かと言ってメソッド内で処理する事はできないようにする予定なので、例外が発生する可能性があるメソッド全てに例外の種類を特定できるような戻り値を与える方向で進めていく予定でやってみます

**デフォルトの名無しさん** · 2020/06/09(火) 05:30:56.43

例外が出る処理はすべてcatch書いて適切な処理を書けばいいだけ。簡単。

**デフォルトの名無しさん** · 2020/06/09(火) 07:53:14.85

>>145
どこでどんな例外が発生するかを全部把握して漏れなくやるのはそれなりに大変だなあ

**デフォルトの名無しさん** · 2020/06/09(火) 08:08:09.91

>>146
かといって、Javaの検査例外の仕組みはちょっとフットワークが重たくなるんだよな。
あれ自体は悪い仕組みじゃないどころか、発想としては初期の割に進んでたんだけど。

**デフォルトの名無しさん** · 2020/06/09(火) 08:50:30.25

全ての例外をcatchすればいいんじゃね？

**デフォルトの名無しさん** · 2020/06/09(火) 09:04:01.05

後にも先にもJavaしか採用していない悪い仕組みだよ
呼び出し階層の途中をすっ飛ばして高層階と低層階の間で例外の関心が繋がるという、
高階関数やフレームワーク等において普通に存在する極めて重要な例外のユースケースを検査例外は無視している

**デフォルトの名無しさん** · 2020/06/09(火) 09:29:05.21

うーん、むしろ、例外が漏れるケース、throwsを書かざるを得ないケースってのを減らすべきだと俺は思ってたけどなぁ。
低層階で発生したものを高層階でハンドリングする事が正しいとはあんまり思わんな。
IOのExceptionみたいな、高層階側ではどうしようもない事を上げられても困ると思う。

**デフォルトの名無しさん** · 2020/06/09(火) 09:44:56.94

検査例外ほんと楽

**デフォルトの名無しさん** · 2020/06/09(火) 10:19:25.97

けんされいがいって何だろうと思って調べたんだが、素人目には良い仕組みに見えてしまった
ただ例外を前提にするなら、もはや例「内」のような気が

**デフォルトの名無しさん** · 2020/06/09(火) 10:21:47.06

Anders Hejlsbirgの検査例外に対する批判
https://www.artima.com/intv/handcuffs.html
検査例外は失敗、とっくの昔に結論出てる

**デフォルトの名無しさん** · 2020/06/09(火) 11:04:45.35

高層側でどうしようもない例外が上がってきてるならそれは下層側が間違ってるだけでは

**デフォルトの名無しさん** · 2020/06/09(火) 11:27:54.89

>>149
>後にも先にもJavaしか採用していない悪い仕組みだよ
Swiftで採用されてるよ
シグニチャによって呼び出し側にエラーハンドリングを強制する方法自体は悪い仕組みではない
例外ではないがRustも考え方としては同じだし>>142の赤間さんの考え方もベースは同じ

**デフォルトの名無しさん** · 2020/06/09(火) 11:29:03.56

チェック例外の発想は悪くないしいい機能だと思うけど、Javaのやりかただとバージョニング諸々で破滅的な事になりがちだから、静的解析なりなんなりのツールで確認すべきかなーっていう主張に読めたんだけど？

**デフォルトの名無しさん** · 2020/06/09(火) 12:02:30.29

何の例外がくるのか意識してかけ派なのか
何の例外も気にするな派なのか
そのどちらであっても書き手の例外テロに強制的に付き合わなければならない
そのごった煮であることを受け入れた上でプロジェクトのスタンスを決めなければならない

**デフォルトの名無しさん** · 2020/06/09(火) 12:06:21.98

>>155
Swiftの例外宣言は「例外を投げる」という指定ができるだけで、型の指定はないよ
>>153の話で言えば、あらゆるメソッドにthrows Exceptionが付けられて破綻した状態を正しいものとして受け容れてるわけ

**デフォルトの名無しさん** · 2020/06/09(火) 12:32:13.75

>>150
呼び出し階層が関心事の包含関係を反映しないケースは普通にある
ラムダなんかいい例で、君は x.Select(y => y.Hoge) でSelectがHogeの投げる例外を知っていなければならないと言ってるんだよ

**デフォルトの名無しさん** · 2020/06/09(火) 12:43:43.58

>>144
例外をエラーコードに変換して何の意味があるのw
例外の発生個所でそれを適切に処理できないなら何もしなくていいでしょw
後々のメンテナンスを考えて、あえてcatchして再スローするコードを書いておくのはありだとは思うけど。

**デフォルトの名無しさん** · 2020/06/09(火) 12:50:07.05

>>149
関心が繋がるって意味が分からないんだが、要するに因果関係があるってこと？

**デフォルトの名無しさん** · 2020/06/09(火) 13:18:10.16

>>159
俺の主張は違うよ。
Hogeは例外を投げてはいけないと言ってるつもり。

**デフォルトの名無しさん** · 2020/06/09(火) 17:30:22.31

>>162
例外を投げることを主張するばかりか、それを上位で処理することを強要する仕組みに賛同してなかったか？

**デフォルトの名無しさん** · 2020/06/09(火) 17:38:45.69

>>163
してないよ。
上位で拾うならアプリケーションを落とすぐらいしかやりようがないって言ってるんだけど。
throwsを書かざるを得ないケースの逆の、書かないケースってどう言う事かわかる？
そのメソッドでは例外が発生しないって事になってるって事だよ。

**デフォルトの名無しさん** · 2020/06/09(火) 17:59:59.91

ホント役に立たない議論好きだな
ここから出ないでずっとやっててくれ

**デフォルトの名無しさん** · 2020/06/09(火) 18:18:44.12

> IOのExceptionみたいな、高層階側ではどうしようもない事を上げられても困ると思う。
どんなに対処してもFileNotFoundExcpetionって防ぎよう無いけど例外受けてUIでエラー表示とかもしないってこと？
低層でexceptionを捕まえて実装者定義の情報に変えてそれでエラーハンドリングしろってこと？

**デフォルトの名無しさん** · 2020/06/09(火) 19:00:49.38

会社の共有フォルダに配置されており、パソコン起動時に実行されて、特定の時刻になったらトースト出すプログラムを作りたいのですが、どのようなプロジェクトが向いていると思われますか？

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

スマートな方法がありましたらご教示下さい

**デフォルトの名無しさん** · 2020/06/09(火) 19:03:38.70

誰がトリガーなのかイマイチわからなかった

**デフォルトの名無しさん** · 2020/06/09(火) 19:11:59.72

>>167
タスクスケジューラとpowershell

**デフォルトの名無しさん** · 2020/06/09(火) 19:13:58.26

>>169
100台近くあるクライアントにタスクスケジューラは辛いです

**デフォルトの名無しさん** · 2020/06/09(火) 19:16:14.88

>>169
ワラタ
全部そいつでいーじゃん

**167** · 2020/06/09(火) 19:26:51.59

クライアントパソコンは起動時に実行ファイルを実行出来る配布済みのものです
実行時に実行ファイルを常駐させる他ないかなと思いつつも適材適所のプロジェクトがあればお伺いしたいなと思っております

**デフォルトの名無しさん** · 2020/06/09(火) 19:30:24.74

>>160
.NETがcatchを強要するようなオブジェクトなんかを用意するから悩んでる
結局その場で何もできないなら多くのサンプルコードのように、catchした例外内容をコンソール上に表示する(または再スローする)だけの形が正解でいいのかな？
呼び出し元にも例外処理させるのはあまりやりたくないけどこういうのは仕方ないのか

**デフォルトの名無しさん** · 2020/06/09(火) 19:43:10.68

>>172
別にWindowsのスタートアップに登録して常に起動させておく方法でも問題ないと思うけど、
どうしても嫌なら既に指摘されてる通りWindowsのタスクスケジューラーのタスクに登録すりゃいいでしょ。

ユーザーにそれを手動でやらせろ、と言ってるわけじゃなく、
あなたが作るプログラムがそれをやればいいってことね。

**デフォルトの名無しさん** · 2020/06/09(火) 19:43:33.99

.Net介してタスクスケジューラにアクセスできるみたいだし無理ではないんじゃね知らんけど

**デフォルトの名無しさん** · 2020/06/09(火) 19:47:14.39

むしろ呼び出し元にも例外処理させるために例外があるんだろ

ファイル書き込みをオブジェクトに任せて書き込もうとしたら書き込めなかった
その後の処理を呼び出し側に書かんでどうすんの？

**デフォルトの名無しさん** · 2020/06/09(火) 19:57:00.94

例外をcatchしたらログに吐き出して上位にthrowすればいいじゃん

**デフォルトの名無しさん** · 2020/06/09(火) 20:20:05.71

Oh...深く考える必要はなかったってことね
まあ例外に関しては立ち止まって考える機会を得れて十分に学習できたからこれはこれで良かったわ