ふらっと C#,C♯,C＃（初心者用） Part148
■ このスレッドは過去ログ倉庫に格納されています
OWINがあるから、CUIでもweb i/fは作れるから
と思ったんだけどね >>94
dockerでフィクスチャ作るような奴欲しい WindowsではOSSが少ないのではなく、64ビットのWindows7が浸透してきたころから
OSSが減ってきているって感じじゃないかな
Win7 64はアプリでもなんでも署名が必要で、特にドライバは署名が正しく行われて
いないと嫌がらせのような開発者モードでしかシステムが動かない
署名が悪いとは思わないけど、署名を取得するには個人の開発者ではまかなうのが
大変なレベルのお金がかかるし、ドライバ作れないのであれば古い機器を有効活用
したりアイデア機器とかも作れないしでOSS作ってくれる層からみるとつまらない
Androidもユーザが自由にやれていたころはOSSが多かったけど、どんどん変な縛りが
増えてPlayに怪しげなS/Wは増えたけどOSSのプロジェクトはどんどん減っている
ちょっとしたアプリなら今でも作れるよねっていうのは分かるけど、大型のOSS
プロジェクトをやってくれる人は、意味のない縛りの多いプラットフォームではやってて
面白くないからWindowsのOSSをどんどんやめていってるんじゃないかな Microsoft自体がOSS推してるのを知らないのか？ 開発リソース割けなくなった製品の姥捨山として考えてるイメージ 質問だけど
Windowsアプリ作るにあたり
VisualBasicを使っちゃいけなくて(好まれなくて)C#を使うべきっていうのは
どういう理由からですっけ？ でもマイクロソフトも新規機能は付けないって言ったり
vbオワコン感あるね
今からやるのは絶対避けた方がいいな >>109
オブジェクト指向言語に寄せていくとC#とかJavaみたいなシンタックスになっていくって聞いたことある。VBみたいな書き方は向いてないんだって。 自分をオブジェクト指向だと思い込んでる手続き型言語のイメージ
クラス定義をしてるというよりも、クラス定義をする命令を書いてる感じがする
End句とか特に >>113
なるほどVBはオブジェクト指向に対応してないと。
これですっきり理解できました。 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 ネイティブアプリを作ってるのですが、
パスワードがかけられたファイルをオープンしたりしようとしています。
コンパイルされるからパスワードはコードにリテラルで書こうと思っています。
が、
c#のコンパイル物の逆コンパイル性はかなり容易なのでしょうか？
Javaはコンパイルしても逆コンパイルで全部戻せれるそうですが。 >>120
C#の逆コンパイルはフリーウェアでほぼ完全にできるレベル >>120
一瞬で逆コンパイルできるから、ソースにパスワード埋め込んだ状態で配布するとか論外 >>120
てかVisual Studio使ってるなら簡単に逆コンパイルできるの知ってるやろ？omnisharpですら最近できるようになったし、昔からilspy等はよく使われてる パスワード判定アプリだけc++で書いてc#からキックするって手もある
わかるやつにはわかっちゃうけど >>120
クライアントに配布する時点で秘匿は無理だと思え >>127
Webアプリに対してクライアント側だけで動作するアプリ、って意味合いでネイティブって言ってるんだろな >>126
重複の上テンプレさえ不完全にされた失敗スレに何を期待しているの？
>>127のようにグーグル検索すら使えない人が来るのに パスを見られたくないのなら認証されたユーザーからの要求があった場合にはサバ側でパス保護ファイルを開いてそのバイナリをネットで送るって形にするしかないな そんな糞めんどくさいことしなくてもインストール時か初回起動時に
ユーザーにパスワード（っていうか復号コードだと思うけど）を入力してもらえばいいでしょw Ruby on Rails では、
暗号化キーのmaster.key は、Github へ保存しないけど、
暗号化済みのcredentials.yml.enc は保存する
それを、master.key で復号すると、YML 形式で、下のような設定が書いてある
aws:
access_key_id: 123
secret_access_key: 345
つまり、暗号化済みの文字列は、公開しておいてもOK。
キーが分からないので、復号できないから
逆に、キーは公開したり、アプリ内に含めるとダメ！ 例外って一度考え始めちゃうとめっちゃ難しいな
色んなサイトのコードとか見てると例外を乱用してるようにしか見えないものが多いように感じる(特にネットワーク関連)
だからといってどこを例外にすれば正しいコードになるのか全然わからん
やっぱり例外処理は全く使わないで済むようにくらいの勢いで想定される例外を自力で検出するのが一番良いんだろうか >>133
なんか基準があるはずよ
落ちるのだけはやめてって言われてるなら
GUIの操作するメソッド全部でcatchしてメッセージでも出さんといかんじゃん
それとも「ああ、死んじゃっていいよ」って言われるかもしれんし
この場合は何もしないし
「ログにだけ出して」
ってのもあるし
そもそも各クラス例外を出す方針に一貫性がない
開こうと思ったファイルが開けないときの動作は普通は例外にしたくないけど例外が飛んでしまうときはcatchしないといけないわけで
まあ、個別に対処が必要？ Rubyの話をする奴は、ちょっと話が違うとか理解することはできんのかな。 >>133
例外は、Catchしたとて復帰不可能なものはアプリケーションエラーにして落とすのに使ってるかな。
そのメソッド内で完結できるならばCatchするというか。
後始末してから結局throwするケースもあるけど。
上っ面がアプリケーションからバッチ処理に変わっても同じように使える事、ぐらいを想定して例外処理書くと統一感出ると思うよ。 >>134
自作だからその辺りの基準はないなあ
とはいえ世間でも基準は割とバラバラなのか
今回作ってるのはネットワーク関連のクラスなんだけど、初めて手を出す分野だからどれが個別に対処できるかは正直よくわかってないんだよね
参考にしてる資料に忠実に作ったら、ちゃんと動くんだけど例外処理だらけなのが見ててすごく気持ち悪くて、これで本当に正しいのかわからなくなったというか
>>136
使い分け方参考になります
あまり考えたくなったけどちゃんとしたものを組むなら例外の内容毎にきちんと仕分けしなきゃだめなのか・・・なんか逆にどんどん複雑になりそうで胸が熱くなるな
こう考えると寧ろサンプルはシンプルに纏まってて良いものに感じてきたわ
例外は普段最低限しか使用しないものだからイメージできなかったけど二人のお陰でなんとなく輪郭が見えてきた気がする、ありがとう >>137
例外って究極のgotoだからね。
その場でやっつけないなら慎重に受ける場所とその後の動きを検討しないといかんよ。
毎回その場でやっつけて、エラーとして呼び出し元に帰すって方針ならそれはそれでいいかも知れんけど、
誰かキャッチするだろって方針で、続行不能だからと適当に例外吐いて落とさせてると、あとで困る。特にバッチ処理。 >>135
そいつはこの板のあちこちに出没する有名な荒しだからスルー推奨。
いくら指摘しても自分に都合のいい話しか目に入らないから相手するだけ無駄で、スレを汚すことになる。 >>138
これはネタで書いたんだろうけど、例外は適切な場所で握りつぶすのが大事だよな。
「知ってる例外はcatchするけどあとはスルー」ってのが最悪。 色々資料をご紹介いただきありがとうございます
つまり、例外が大好きな.NETを呪いながら潰せる例外はメソッド内で潰し、潰せなければどのような例外があったかをきちんと調べられるようにすれば良いわけかな
今回は例外が発生してもクラッシュせず、かと言ってメソッド内で処理する事はできないようにする予定なので、例外が発生する可能性があるメソッド全てに例外の種類を特定できるような戻り値を与える方向で進めていく予定でやってみます 例外が出る処理はすべてcatch書いて適切な処理を書けばいいだけ。簡単。 >>145
どこでどんな例外が発生するかを全部把握して漏れなくやるのはそれなりに大変だなあ >>146
かといって、Javaの検査例外の仕組みはちょっとフットワークが重たくなるんだよな。
あれ自体は悪い仕組みじゃないどころか、発想としては初期の割に進んでたんだけど。 後にも先にもJavaしか採用していない悪い仕組みだよ
呼び出し階層の途中をすっ飛ばして高層階と低層階の間で例外の関心が繋がるという、
高階関数やフレームワーク等において普通に存在する極めて重要な例外のユースケースを検査例外は無視している うーん、むしろ、例外が漏れるケース、throwsを書かざるを得ないケースってのを減らすべきだと俺は思ってたけどなぁ。
低層階で発生したものを高層階でハンドリングする事が正しいとはあんまり思わんな。
IOのExceptionみたいな、高層階側ではどうしようもない事を上げられても困ると思う。 けんされいがいって何だろうと思って調べたんだが、素人目には良い仕組みに見えてしまった
ただ例外を前提にするなら、もはや例「内」のような気が Anders Hejlsbirgの検査例外に対する批判
https://www.artima.com/intv/handcuffs.html
検査例外は失敗、とっくの昔に結論出てる 高層側でどうしようもない例外が上がってきてるならそれは下層側が間違ってるだけでは >>149
>後にも先にもJavaしか採用していない悪い仕組みだよ
Swiftで採用されてるよ
シグニチャによって呼び出し側にエラーハンドリングを強制する方法自体は悪い仕組みではない
例外ではないがRustも考え方としては同じだし>>142の赤間さんの考え方もベースは同じ チェック例外の発想は悪くないしいい機能だと思うけど、Javaのやりかただとバージョニング諸々で破滅的な事になりがちだから、静的解析なりなんなりのツールで確認すべきかなーっていう主張に読めたんだけど？ 何の例外がくるのか意識してかけ派なのか
何の例外も気にするな派なのか
そのどちらであっても書き手の例外テロに強制的に付き合わなければならない
そのごった煮であることを受け入れた上でプロジェクトのスタンスを決めなければならない >>155
Swiftの例外宣言は「例外を投げる」という指定ができるだけで、型の指定はないよ
>>153の話で言えば、あらゆるメソッドにthrows Exceptionが付けられて破綻した状態を正しいものとして受け容れてるわけ >>150
呼び出し階層が関心事の包含関係を反映しないケースは普通にある
ラムダなんかいい例で、君は x.Select(y => y.Hoge) でSelectがHogeの投げる例外を知っていなければならないと言ってるんだよ >>144
例外をエラーコードに変換して何の意味があるのw
例外の発生個所でそれを適切に処理できないなら何もしなくていいでしょw
後々のメンテナンスを考えて、あえてcatchして再スローするコードを書いておくのはありだとは思うけど。 >>149
関心が繋がるって意味が分からないんだが、要するに因果関係があるってこと？ >>159
俺の主張は違うよ。
Hogeは例外を投げてはいけないと言ってるつもり。 >>162
例外を投げることを主張するばかりか、それを上位で処理することを強要する仕組みに賛同してなかったか？ >>163
してないよ。
上位で拾うならアプリケーションを落とすぐらいしかやりようがないって言ってるんだけど。
throwsを書かざるを得ないケースの逆の、書かないケースってどう言う事かわかる？
そのメソッドでは例外が発生しないって事になってるって事だよ。 ホント役に立たない議論好きだな
ここから出ないでずっとやっててくれ > IOのExceptionみたいな、高層階側ではどうしようもない事を上げられても困ると思う。
どんなに対処してもFileNotFoundExcpetionって防ぎよう無いけど例外受けてUIでエラー表示とかもしないってこと？
低層でexceptionを捕まえて実装者定義の情報に変えてそれでエラーハンドリングしろってこと？ 会社の共有フォルダに配置されており、パソコン起動時に実行されて、特定の時刻になったらトースト出すプログラムを作りたいのですが、どのようなプロジェクトが向いていると思われますか？
WPFのプログラムを起動して5分おきに時刻をチェックし時間になったらトースト通知という仕組を考えたのですが、タスクバーに常駐してるのもなぁと思いまして
スマートな方法がありましたらご教示下さい >>167
タスクスケジューラとpowershell >>169
100台近くあるクライアントにタスクスケジューラは辛いです クライアントパソコンは起動時に実行ファイルを実行出来る配布済みのものです
実行時に実行ファイルを常駐させる他ないかなと思いつつも適材適所のプロジェクトがあればお伺いしたいなと思っております >>160
.NETがcatchを強要するようなオブジェクトなんかを用意するから悩んでる
結局その場で何もできないなら多くのサンプルコードのように、catchした例外内容をコンソール上に表示する(または再スローする)だけの形が正解でいいのかな？
呼び出し元にも例外処理させるのはあまりやりたくないけどこういうのは仕方ないのか >>172
別にWindowsのスタートアップに登録して常に起動させておく方法でも問題ないと思うけど、
どうしても嫌なら既に指摘されてる通りWindowsのタスクスケジューラーのタスクに登録すりゃいいでしょ。
ユーザーにそれを手動でやらせろ、と言ってるわけじゃなく、
あなたが作るプログラムがそれをやればいいってことね。 .Net介してタスクスケジューラにアクセスできるみたいだし無理ではないんじゃね知らんけど むしろ呼び出し元にも例外処理させるために例外があるんだろ
ファイル書き込みをオブジェクトに任せて書き込もうとしたら書き込めなかった
その後の処理を呼び出し側に書かんでどうすんの？ 例外をcatchしたらログに吐き出して上位にthrowすればいいじゃん Oh...深く考える必要はなかったってことね
まあ例外に関しては立ち止まって考える機会を得れて十分に学習できたからこれはこれで良かったわ >>149
>呼び出し階層の途中をすっ飛ばして高層階と低層階の間で例外の関心が繋がるという、
それは例外機構そのものの問題だと思うがな。
検査例外はそれを静的にチェックするからすぐ目に付くけど、それ以外の言語は
その関係が動的暗黙的で表に見えないだけ。ある意味よけい悪い。 >>173
何もしないならその場でcatchしちゃだめだって
ログ出力のような共通処理は集約例外ハンドラに任せる まず、大原則を覚えてください。
よほどのことがない限り、アプリケーションで try-catch を書いてはいけません。
もう一度繰り返します。
よほどのことがない限り、アプリケーションで try-catch を書いてはいけません。
もう一度(ry、すみませんしつこいですね^^。でもこれ、めちゃめちゃ重要なのです。
https://docs.microsoft.com/en-us/archive/blogs/nakama/net-part-1
賛同するかどうかは別だけど
これがMS推奨の定跡 >>181
嘘だよ
まず、アプリケーションをストップさせたくないときはcatchしないと駄目だよ
そもそもファイルがない程度で例外出しやがるお前（Microsoft）みたいなのがいるから足並みが揃わないんだろうが
そもそもみんな例外の扱いに困ってんのはお前（Microsoft）のせいだお前（Microsoft）の
それと例外自体が造り手の思想依存であって
飛んできた例外に例外であることの正当性の保証はない
みんながみんな好き勝手飛ばすし
正当な処理結果なのに例外としてcatchさせるような作り方もできる
こんな状況なので方針というのは作れなくて1つ1つのメソッドでどういう動作にするか考えなくてはならない >>180
キャッチしないとその場でクラッシュするから・・・
例えば、通信先の接続に失敗しただけで例外になるからこれでクラッシュするのは避けたいって時とか
そうすると色々教えてもらった結論としてはcatchしてから何もせず再スローするしかないと思ったんだよね
でもやっぱり気持ち良いものではないから代替案があればそっちにしたいけどいかんせん俺の知識が足りない >>185
すまん、集約例外ハンドラが全然理解できてなかったから頓珍漢なこと言った
ちょっとちゃんと読ませてもらうわ >>183
FileNotFoundExceptionが出て欲しくないなら
きちんと事前にファイルの存在を確認すれば良いだけだろ ファイルの存在確認してからファイルオープンの間までにファイルが消えることがあるんですが… ライブラリ内、関数内でcatchして、ファイルが無かった旨の結果を返すか、
(必然的に、成功、失敗のいずれかと付随する結果を持つ結果オブジェクトを返すことになる)
もしくは誰もキャッチせずアプリケーションエラーにしてアプリごと落としてしまうのが良いんじゃないの？
要は、ファイルが無い場合ってのは、それをもってなにか処理したい場合、正常系の1パターンであって、無理に救う異常系ではないと思う。 結局どの階層でもファイルが見つからない状況に興味がなければ
そのアプリは落ちるしかあるめえなあ >>189
落とした方がいいかどうかなんて
そんなのお前が決める問題じゃないじゃん 作るメソッドが例外を飛ばしまくるくせに
ドキュメントを書かないなんて奴は最悪で完全に制御するためには
メソッドの中のソース読んで例外が今回の仕様にマッチするかどうかまで調べないといけない現実
ファイルがなかったから飛んだ例外なのかファイルを開いて編集できなかったから飛んだ例外なのか
造り手はそれに気を使う義理はないが キャッチされなかった例外はそのまま上位へ伝播したとおもったが >>196
それであっているしそうしないとthrowの意味が半減する
catchして何か処理したうえで再スローするのならともかくそのままthrowって言っている>>193とそこで止まるって言っている>>195は例外処理の基本すらわかっていない >>199
検査例外の対応がそうするのが主流ってことか？ ■ このスレッドは過去ログ倉庫に格納されています
