#設計思想的な話になると思うのですが
#(test* "Checking VACUUM"
#f
(dbi-do connection "VACUUM"))#こんな感じのdbi-doがコケたときSchemeの流儀としては#fを期待するのと#<error>を期待するのとどっちがより一般的なんでしょ
#discrepancies found. Errors are:
test Checking VACUUM: expects #f => got #<<error> "cannot VACUUM from within a transaction">
#こんなのを見掛けたので、まぁVACUUMなんかそうそう使わんよなと思いつつ。どうあるべきなのかなぁと疑問に思ったので。
##t以外が返されたらその時点でアウトだろ、って気もするんですけど...
#Schemeの流儀って話よりは、dbi-doの仕様をどう決めてるか(決めるべきか)って話ですよね。
#今はdbi-doはdbdに丸投げなんで、各dbdの動作がそのまま透けてみえると。その状態で「エラーを返すdbdもあれば、#fを返すdbdもある」っていうなら、「#fか(test-error)」をテストすべきってことになるんじゃないかな。
#なるほど。ちょっとdbiと各dbdの挙動を眺めてみます。WiLiKiかどこかに設計メモ的なのあるかな（まだ真面目に探してない）
#設計メモって書いた覚え無いなあ。多分意図を説明しているのはコードのコメントとリファレンスマニュアルのみで、そこに買いて無かったら設計時に考慮していないという可能性大。
#形は何であれ書いた人の意図がわかるとやりやすいですよね。どうしてそうなってるのかわからないと途方に暮れる ;-)
Gauche > Archives > 2012/01/05