ちゃっぴの監禁部屋

ガチガチに締めすぎて動きがとれなくなる。。。

ホーム 連絡をする 同期する ( RSS 2.0 ) Login
投稿数  405  : 記事  5  : コメント  12076  : トラックバック  134

ニュース

記事カテゴリ

書庫

日記カテゴリ

Communities

Personal Information

File 操作を行う際、存在確認は行わないほうがよい で書いたんですが、どうも事前に確認すれば問題ないと考えている人がかなりいるようなので再び書きます。

事前確認が確実に保障されるものは非常に限られます。その process で扱える private memory のみです。Multi thread で動作させる application であればそのうち lock した memory のみという条件がそれに加わります。それ以外は事前確認の結果が保証されません。

事前確認が確実に有効な状況というのは非常に限定的であることに注意してください。

つまり、事前確認を行ったところで結果が保障されないわけですから、事前確認を行わない前提の例外処理を必ず組み込まなければなりません。

その上で事前確認を行うか?判断することになります。この場合の事前確認を行うか否かの判断材料は主に performance でしょう。といっても正常系ではなく、例外系の処理での performance です。例外系の performance が重要であれば実装する。重要でなければ実装する必要は無いと思います。

危惧しているのは安易な事前確認でその結果が保障されていると勘違いする人が出てくることです。これを履き違えると脆弱性を作りこむことにつながります。

その application が排他的に扱えるものでない限り事前確認は信用してはいけない。非常に重要な原則です。

投稿日時 : 2008年3月14日 2:51

コメント

# re: 事前確認が保障されているものと保障されていないもの 2008/03/14 8:51 myugaru
なんだか確認症候群の話を聞いているようです。
やりすぎ、の「すぎ」の定義は難しいですね。
結局、「毛が一本はハゲか?じゃあ何本からハゲと呼ばれない?」みたいな不毛な会話にならないことを祈ります。


# re: 事前確認が保障されているものと保障されていないもの 2008/03/14 9:05 myugaru
えっと私はちゃっぴさん寄りの人間です。
なのでむしろちゃっぴさんを応援したい、って意味です。すみません。

ちなみに私は確認症候群かもしれません。
事前確認もしっかりしたいし直前直後の確認もしっかりやりたい派です。
でもそんな自分が正直うんざりです。
メインの処理よりそういう余計な事にばかり気をとられます。
なので.NETのリソースを管理してくれる環境がとても好きです。ってかもうネイティブには絶対絶対戻りたくないし戻れません。

以上です。

# re: 事前確認が保障されているものと保障されていないもの 2008/03/14 11:10 とっちゃん
事前確認(アサーションチェック)は、外部入力情報の確認用かな。

引数の類は、基本的にアサーションかけて、その上でパラメータチェックするというのが、ライブラリビルダーの鉄則です。

可能な限り、開発初期の状態でバグの種をまかれないようにするというのは、かなり労力のかかる作業なんですが...(人も機械もw)

ファイル操作系での事前チェックは、せいぜいファイル名が正しいか?とかその程度かな。

最近注意しないといけないなぁと思うのは、セパレータ(/や\)が2個並んではいってきた場合。
これ、OSによっては開けちゃうんですが、開けない環境もあるんですよね。
なので、忘れてなければ、自動生成でもパス名として正しいか?
はチェックするほうがいいです。

こういう不毛なバグってのは、なかなか見つけられないので...w


# re: 事前確認が保障されているものと保障されていないもの 2008/03/16 23:02 ちゃっぴ
> なんだか確認症候群の話を聞いているようです。

確認症候群というよりも、本質を理解しようよというのが主旨です。

本当は違うのに確認して OK なつもりになっている。そういうのが危険なわけです。

まあ、私の場合は確認症候群というよりやりすぎ症候群の嫌いがありますが。

> 引数の類は、基本的にアサーションかけて、その上でパラメータチェックするというのが、ライブラリビルダーの鉄則です。

ここら辺をもっちと詳しくお願いします。

> ファイル操作系での事前チェックは、せいぜいファイル名が正しいか?とかその程度かな。

この場合は結果が保障されていますからね。

# re: 事前確認が保障されているものと保障されていないもの 2008/03/17 19:05 とっちゃん
>ここら辺をもっちと詳しくお願いします。

ライブラリは使われてなんぼな世界なので、いかに使いやすく作られているか?
というのが重要というのはわかると思います。

そして、それと同時に、どれだけ早いタイミングで間違った使われ方をはじけるか?
も実は重要な要素の一つなんですよ。

なので、デバッグ版であれば、これでもか!というくらいアサーションかけまくっていたりします。
#あまりに過度になると、想定してるダメな状態までアサーとされちゃうんで、難しいところですがw

要するに、どこまで再利用しやすい(そのまま使いまわせる)かというところにどれだけ開発コストをかけるか?ということですがねw

ぶっちゃけ、ダメならダメって言ってよ~をどこでやるか?ということなんですがねwww

>この場合は結果が保障されていますからね。
この場合の結果は、「保障」ではなくて「保証」です。
typoかもですが、意味が違います。


# re: 事前確認が保障されているものと保障されていないもの 2008/03/17 22:30 ちゃっぴ
ここで言っている assertion は debug 時に使うあれですか?
これに対し parameter check は通常の処理系での確認?
でいいんですか?

う~む。どれだけ早い timing ではじけるか?というのも場合によっては非常に重要になると思いますけど、それよりも一つの class, function 単位で絶対に問題が発生しないようにしたほうが使いまわしが楽なんではないでしょうか?

もしかして早くというのは debug 時に bug 潰せるか?ということでしょうか?それなら全く同意です。

> この場合の結果は、「保障」ではなくて「保証」です。
> typoかもですが、意味が違います。

ですね。気にしてなかったorz

# re: 事前確認が保障されているものと保障されていないもの 2008/03/18 12:30 とっちゃん
>ここで言っている
デバッグ版なら、assertion して、なおかつ parameter check して、エラーリターンです。というか、ライブラリじゃなくてもデバッグ版ならこれくらいやるのが普通なんですがねw<本来なら...

リリース版では、デバッグバージョンのアサーションコードは動きません。
なので、独自にアサートシステムを作り上げたり、パラメータチェックの時点で致命的(たとえばバッファサイズが超えてるのが明確など)なエラーは、メッセージを出してでもブロックする。
それくらいのアフターケアは当然のごとく行っていますし、それくらいところまで面倒みてないと、バグの早期発見にはつながらないんですよ。

エンドコードを単体テストしてる時点で、ライブラリサイドからも簡易的なテストを施すという格好まで持ち込んでおけば、ステップあたりのバグは成立は、よく言われる数値の数万分の一の規模にまで減らせます。
それくらい、ミスが多いのがパラメータの内容だったりするわけです。

なので、ライブラリ自身の異常系単体テストなんかした日には、アサートのあらしです(自動化なんて夢物語www)。
#本来それくらいがっちりアサーションかけてないと安定度を確保できないんでw

class や function の単位で問題が発生しないように作るというのは、議論の余地なく大前提です。
最低限このレベルに近い状況(絶対と書けないのには理由がある)にはなっていないと、ライブラリとして使い回しはできません。

それでもなお、さまざまなアサーションやパラメータチェックが入るのは、ライブラリの場合使ってもらってなんぼというのがあるため、実装時点では想定していない状況で使われることが前提だからなんです。

場合によっては、ライブラリの変更を必要とするものもあるでしょうし(OSのバージョンアップなどはこれに相当する)、社会の変化などもあるでしょう(元号に平静が加わったなどはこれに相当する)。

これらは外部要因ですが、手離れの良いライブラリというのは実質的にメンテフリー状態になってしまうため、エラーチェックを自ら施していないと想定外の状況が発生してしまいかねません。

実際、内にある社内ライブラリのいくつかは、5年とかという単位ではなく、10年という単位で、ソースをいじっていないものとかもあります。

今のところ、運よく変化の影響は受けていませんが、そういう状況下でもチェック機構がしっかりしてれば自爆の危険は回避できるわけです。

ライブラリのバグは、場合によっては会社の命運すら左右しかねないほどインパクトのある状況になりかねませんからね。


# re: 事前確認が保障されているものと保障されていないもの 2008/03/20 0:07 ちゃっぴ
おっしゃっていることは非常によくわかります。

今までは、test code を別に書く程度で assertion を積極利用したことが無かったので非常に参考になりました。

Library を作成する上での心得もしくは、best practice なんてやっていただけると喜ぶ人結構いるんじゃないかなぁ~と思ってみたり。

# re: 事前確認が保障されているものと保障されていないもの 2008/03/21 12:19 とっちゃん
>喜ぶ人
いるのかなぁ?
あんまりいない気がするけど...どうなんだろ?w


ぶっちゃけ、ライブラリを整備できるってかなり恵まれてるほうなんだと思いますよ。

それだけ使い回しできるコードがある(=同じことをやってる)というわけですから...

.NET を使っていいとなれば、今うちにあるようなライブラリは大半が姿を消す(.NET にすでに同じようなものがある)だろうし...

ま、全部なくなるということはないですけどねw
#東京3のえムナウさんのセッションとかはまさにライブラリを作るに等しいネタだしw


# re: 事前確認が保障されているものと保障されていないもの 2008/03/21 22:27 ちゃっぴ
> #東京3のえムナウさんのセッションとかはまさにライブラリを作るに等しいネタだしw

うわ!みていない。。。早速 check しなくては。。。

# re: 事前確認が保障されているものと保障されていないもの 2008/03/22 11:35 とっちゃん
かなり古いやつだからねぇ。見てない人も結構いると思う。

まま、暇がある時にゆっくり見てくださいw
古いネタは、結構設計よりなやつが多いです。

最近のははやりもの(LINQ/WPFなどなど)が中心なんで、今とはちょっと違う側面が見れますよw


Post Feedback

タイトル
名前
Url:
コメント