Swiftのエラーハンドリングはなぜ最先端なのか - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
とあるコンサルタントのつぶやき - Site Home - MSDN Blogs
MCS （Microsoft Consulting Services） の某コンサルタントがまったり語るテクノロジのお話です。 触って覚える Microsoft Azure 今日から TechSummit 2018... Author: nakama Date: 11/05/2018 Docker for Windows & Web Apps for Containers 実践活用技法 先日、しれっと営業部門のクラウドソリューションアーキテクトに異動した話を書いたのですが、このロールは Azure... Author: nakama Date: 09/27/2018 Agile も DevOps も銀の弾丸なんかじゃない ……と、のっけから噛みつかれそうなタイトルを掲げてみたのですが；、ここ最近、立て続けて数件、「いやそれはアジャイルとか無理だろ；」的な話があって、ちょっとエントリを書いて
例外をどう書くか - ma2’s diary
Webアプリのメンテナンスをしていて，例外の扱いがいい加減なのが気になり（元は他人のコード），例外周りを整理しようと思い立った。さてJavaの例外はどう扱うのがスマートか。色々探してみて，役に立つと思ったのが以下の3つ。 例外(Exception)脳の作り方 戻り値にエラーコードをセットするぐらいなら例外を投げよう そうすれば正常系だけがコードの前面に出るヨ めっちゃ分かりやすいっす。例外のうまい使い方が納得できるなあ。ここでは自分で分かりやすい例外クラスを作って活用する方針。 Best Practices for Exception Handling checked exceptionは使うな（情報の隠蔽が壊れる） 自分で例外クラスはあんまり定義するな（標準の例外クラスを使うかRuntimeException("custom error")を使え） という方針で，例外をuncheked
using 構文使用時に Dispose が呼出されない確率 - NyaRuRuが地球にいたころ
以前から何度か取り上げているネタですが，実際のどれぐらい起きるものか気になって試してみました． 下のように延々と new と Dispose を繰り返しているスレッドをランダムに Abort させてみると，非常に小さい確率ですが，new されたオブジェクトの Dispose 呼出しが行われないという現象が発生します． while (true) { using (MyDisposableObject obj = new MyDisposableObject()) { } }手元の環境で試してみたところ，20,000 回の試行で 4 回ほど発生しました．0.02 % ぐらいです．これは using 構文の中身が空の場合の結果なので，実際にはもう何桁か発生確率は下がるかと思います． ソースコードはこちら． http://www.dwahan.net/nyaruru/hatena/UsingTes
例外との正しいつきあい方
例外ってなに? プログラムを書いていると、try ... catch を書くのがめんどうになったことはありませんか。 たとえば、リスト 1 はファイルを読み込んで単に標準出力に出力を行うプログラムです。これを javac でコンパイルすると、図 1 のようにコンパイルエラーが起きて、コンパイルできません。そこで、「しょうがない、try ... catch を書くか」といって、リスト 2 のように書いたとします。「これでコンパイルはできたから OK」と済ませていませんか。 これでは例外から得ることのできるさまざまな有用な情報を捨ててしまっています。それだけでなく、想定していた動作を行うことができないかもしれません。 逆にいえば、例外を有効に使いこなせるようになれば、プログラムの堅牢性を高めることができ、また保守性も向上させることが可能です。そんな例外の基本から例外を使いこなす
例外機構を台無しにする巷の実装者たち
Javaには，異常系の処理を正常系の処理から明確に分離し，異常系の対処を実装者に強制することでコードの質を半強制的に高めるための「例外機構」が備わっている。例外は，チェックされるべき例外（Exceptionの直系）と，チェックしなくてもいい例外（RuntimeExceptionの系列）の２種類があり，「実装者に例外発生時の対処をさせるかどうか」でどちらを使うかを判断する。 多くの場合，業務的な例外はチェックされる例外，環境的な異常などの状況にはチェックされない例外が使われる。環境系の異常（ネットワーク異常，ファイルアクセス異常など）はアプリケーション内で共通的に処理されるだろうから，実装者にいちいち対処のコードを書かせる必要はない。それとは逆に，業務的に通常とは違う状況となった場合，その業務を使った局面によってその内容が変わる可能性があるので，業務それぞれで矛盾がない状態にしてあげるために
匣の向こう側 - あまりに.NETな#p1
仕事上ではC/C++を使っていて、エラー処理等は全て戻り値でやっているのですが、.NETだとクラスライブラリが例外を返してくるので、例外処理付き合わざるを得ません。私の例外処理に対する知識は10年以上前にC++の勉強で身につけたものでして「例外はあくまでも例外。通常は起こるはずが無いもの」となっています。しかし、「OSの異常」みたいなのだと話は簡単なのですが「業務上あり得ない」とかになってくると境界が曖昧になって悩みます。 それはさておき、メソッドが例外を返すとされている場合、 呼び出し側のミス(nullを渡すな等) メソッド内部で起こった異常 と、大ざっぱに分けられます。1.はバグなので出荷時には潰されているべきものでしょう。さて、2.については、呼び出し元の責務によって対応が変わってきます。 例外処理をどう扱えば良いか、イマイチよく分かっていないので、現在、自分が考えていることをつらつ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サービス終了のお知らせ
Technical documentation