Fork me on GitHub
#clojure-japan
<
2015-06-16
>
kara_d04:06:52

ちょっと聞いてみたいことがありまして、ネタ投下します。

kara_d04:06:25

みなさん、コンディションマップって使ってますか?あと、使ってるとしたら、エラーハンドリングどうしてます?

kara_d04:06:55

(defn p [x] {:pre [(or (some? x) (throw (ex-info "NILL ERROR" {:causes #{:nill-error}})))] :post [(= % 2)]} (+ x 1))
みたいにex-infoとかでやったりとかしてるのかとか。

athos05:06:13

コンディションマップで指定できる:pre/:postは、いわゆる契約プログラミングにおける事前条件/事後条件なので、原則的にはそれらの条件を満たさないような状況っていうのは開発時にすべて取り除かれるべきで、実行時には基本的に起こりません

kara_d05:06:17

ふむふむ、なるほど

kara_d05:06:01

https://github.com/Prismatic/schema の代わりみたいにつかうのは変な感じなんでしょうか?

kara_d05:06:15

ちなみに、スタイルガイドにも https://github.com/totakke/clojure-style-guide#pre-post-conditions こんな記述もありまして。。

ayato_p05:06:51

:pre/:post ってやってること他言語でいうアサーションと同じですよね。僕はエラーハンドルとかしようとしないでアサーションエラー飛ばしてしまいますね。基本的に開発時にその関数の期待値を明確化するという意味合いの方が強い気がしていますし。

ayato_p05:06:49

schema の代わり、というのはちょっと分からなかったです。

ayato_p05:06:12

(別に他言語っていわなくても Clojure でもアサーションですね)

kara_d06:06:56

なるほどなるほど、ありがとうございます。

kara_d06:06:10

ちなみに、https://github.com/Prismatic/schema の代わりと書いたのは引数のバリデーション的に使ったらどうだろと思い書いた次第です。

ayato_p06:06:35

実際バリデーションのように使いますよね?その目的が若干違うだけだと僕は思いますよ。

ayato_p06:06:37

(defn foo [m] {:pre [(map? m)]} (do-something))

ayato_p06:06:41

みたいに。

athos07:06:29

離脱してました

athos07:06:37

:pre/:postの違反で出るエラーを捕捉して処理するみたいなことはやらないで、普通はAssertionErrorが出るに任せるんだと思います

athos07:06:03

契約プログラミングの事前条件/事後条件って、型チェックをより強力にしたような感じで、AssertionErrorも本来はコンパイル時に検出したいことを実行時にしか検出できないから実行時にエラーとして出している、ぐらいのものだと思ってます

athos07:06:28

あー、言語によっては事前条件/事後条件の違反もコンパイル時に検出できるという話は聞くので、一応そこは補足しておきます

ayato_p07:06:56

Eiffel とかがそうなんですかね?

athos07:06:27

はいはい、あとDもって話を聞いた気がします

ayato_p07:06:52

Clojure では契約プログラミングそれそのものをサポートはしていないけど、 :pre/:post を使うことで契約プログラミングぽく表明出来るよーということですよね。

athos07:06:36

ですね。Clojureだとcore.contractsもありますけど、どこまでできるのかは把握できてないです

athos07:06:31

あ、でSchemaとの絡みの話でいうと、Schemaはバリデーション(信用できない入力に対するチェック)用のライブラリで、バリデーションの結果入力が期待した値でなかった場合でも適切に例外処理をすれば復帰することができますが、AssertionErrorの場合は起きてしまったらそれはバグなので復帰のしようがないって違いはあるかと

ayato_p07:06:19

おお、僕が言葉にできなかったモヤモヤが言語化されている

athos07:06:09

Schemaを事前条件/事後条件に使うこともできなくはないかもしれないですが、それはSchema本来の使い方ではないと思います

kara_d07:06:40

> Schemaとの絡みの話でいうと、Schemaはバリデーション(信用できない入力に対するチェック)用のライブラリで、バリデーションの結果入力が期待した値でなかった場合でも適切に例外処理をすれば復帰することができますが、AssertionErrorの場合は起きてしまったらそれはバグなので復帰のしようがないって違いはあるかと ですごくすっきりしました!

fanannan11:06:44

schemaは型チェックの有効無効が切り替えられたんではなかったですかね。そのあたりも便利ではないかと。

fanannan11:06:56

またネタ振りだけですが、nekoがバージョンアップですね。実用性上がってたらいいですね。http://clojure-android.info/blog/2015/06/16/neko-400alpha1-changes-and/?utm_source=dlvr.it&amp;utm_medium=twitter

athos21:06:27

たしかに僕の発言はschema.core/validateにしかフォーカスしてなかったですね。s.c/defnとかまで考慮すればそうですね。

ayato_p23:06:49

Android は完全に Kotlin が制圧し始めている感じあって、 Clojure で書けて嬉しいのは Clojure 使いだけみたいな感じですよね。 僕らは嬉しくても Android やってる人が流れてくることはないんだろうなーという目で見ています。 > neko