年取ると、感覚は鈍るというものだと思っていたが、実は違うのではないかという気もする。明らかに、遠視が入ってくるから視るモノについては衰えたと言い切れる。蚊が飛ぶ音みたいなやつは、まったく聴こえないから、これも可聴音域が狭くなったと言えるだろう。ところが、味覚(実際には舌はほとんど大した感覚がなく、嗅覚の影響が大きいらしいので、その意味では嗅覚かも知れない)については違う。鹹味と甘味については鋭敏になっている(というのは、以前だったらあり得ないくらいの少しの味付けで十分にそれが機能するし、子供の頃だったらほとんど味を感じない=まずい野菜というような位置づけだった白菜やら水菜やらが実にうまく感じる)ように思える。機能的に加齢によって味覚だけが鋭くなるということは考えにくい。その一方で、味覚の大家は海原雄山のような老人と昔から相場が決まっている(印象論ではなく、実際にそうなんだろうと思う)。ひとつは、いろいろうまいモノを食ってきたので黒白つけやすくなっているとか、基準点を確立しているといったことはあるかも知れない。それだけでは若い感覚に勝てることはないだろう。別の何かがあると考えるほうが自然だ。それにしても、通念として老人はあっさり味が好みとされているが、そうではなく、若い調理人にはあっさりしていると感じる味付けの中に深い味わいを得ているというのが真相に思える。そこで、次のような仮説を立てた。蚊の音のような高周波ということで、ケータイの若者にはちゃんと言葉が聞こえるが老人(中年も含まれるように思う)には聞こえないというやつが出回っていて、妻と子供が遊んでいたが、どうも、逆に子供には老人が聞こえる音は聞こえていないようだ(なので、遅回しによって示す必要がある)。いうことは、高周波(というよりも人声というわかりやすい音)によりマスキングされているということではなかろうか。それによって老人が聞こえる音が聞こえない。鹹味と甘味に対して子供になればなるほど鋭敏で、それにより他の雑味がマスキングされてしまう。そのために微妙な味わいを感じることができない。その結果として深い満足を得ることができないために、さらに鹹味や甘味を強調した味付けを求めてしまい、ますます雑味をマスクしてしまい単純な味を感じ取る。それが加齢によって鹹味や甘味に鈍くなることでマスキング効果がなくなり雑味をはっきりと感じ取ることが可能となる(その一方で、他の味(あるいは香り)と混合されることで、微量であっても鹹味や甘味を検出できる)。そのため、老人のほうが料理の深い味わいを楽しめる。この季節は白菜がうまいし、鱈の鍋とか子供の頃はまったくうまいと思わなかった食い物がうまい。識別出来る種類(組み合わせも種類として)が増えるというのは納得出来ます。[特定領域向けはそれなりに使われるようになっていると思います。[洋酒メーカーというのはちょっと予想外ですね。言われてみるとなんか想像つくけど。Monoミーティングさくらインターネット研究所のセミナールーム。電源と無線LAN完備で、申請ー承認で無料というのはすごい。場所は角筈、アスキーの近く。Azureに対するODataはマルチパートマイム(カタカナで書くとすごいな)でトランザクションだそうだ。serviceも同じか調べてみよう。追記:多分大丈夫そうだが試すのは難しい。FrameworkのException.StackTrace追記:間違ってるところを修正。昨日、同僚と例外を出しまくるテストをしていて恐ろしいことに気付いた。次のようなメソッドをクラスライブラリで用意したのだった。LoggerはeのStackTraceプロパティをログする。...}おれの作ったクラスライブラリは、Java流儀というか、引数のnullチェックみたいなくだらないことはしない。いうものは下位のクラスライブラリに任せる。したがってnullが与えられるとRegex.MatchがスローするArugmentNullExceptionを取る。(さすがにこれは例が単純過ぎるが、本来はいろいろな例外が引数によって発生する可能性がある)しかし、ライブラリのユーザがまじめに例外を処理することはあまり期待しない。すればOKだがしなくてもそれはその時だ。そこで、後で原因がわかるようにこちらで例外を受けたらログをするわけだ。やってnullを与えたりその他の(上の例だとちょっと他の例は考えにくいが)エラーになるパターンを与えたりしてログにさんざん書き込んだ。s)になっているからだ。このトレースみたら、悪いのはFooメソッド以外に存在しないことになってしまう。Frameworkのアセンブリの直前のアセンブリの最初のメソッド)でスタックトレースが切られてしまうようだと気付いた。いや、これはクラスライブラリを提供する側にとっては致命的だよ。誰が呼び出したかを調べるためにトレースを残そうとしているのに、それが残らないわけだから。0にするとロガーのこのメソッドになってしまうlogFile.WriteLine(st.ToString());と書き出すようにして決着。おれの設定とかがおかしいんんじゃないかという気がするわけだ。追記:さらにいろいろ試すと、System.Diagnostics.StackTraceはフレームの位置を決められるというメリットはあるけれど、行番号をまったく残してくれないことに気付く。すると、Environment.StackTraceのほうが行番号が付くから良いかも(しかし先頭2つがEnvironmentになってしまうのがいやな感じだ。いうか、PDBファイルを置かなければいずれにしても行番号は無いはずだから、Diagnosticsのやつでも同じかなぁ。[アセンブリ境界でスタックトレースが切れるって事象は出たことないです(今試しましたが再現せず)。[あ、すみません、勘違いしていました。呼び出し元を取りたいのですね。[どうもありがとうございます。いやー、結構知らないことがたくさん。FrameworkのException.StackTrace追記:matarilloさんからのツッコミを受けて、Backyardへ修正版を作成。いうわけで、以下でInnerExceptionとアプリケーションログの関係について記述しているところは正しくはありません。昨日は、yfakariyaさんやmatarilloさんからいろいろ指摘を受けたので、あらためてMSDNを読んでExceptionクラスが返すものをチェックしてみた。結論から言うと、アプリケーションとライブラリでは同じExceptionオブジェクトでも(少なくとも後からの調査用のログという観点からは)見るべきプロパティを変えるべきだ。以下のテストプログラムを用意した。Fooメソッドは呼び出し先メソッド(当然ライブラリを想定する――アセンブリの違いというのは全くの誤解釈だとわかったので同一クラスでも良い)を信用していない。したがって、このメソッドが採取すべきログは呼び出し先の振る舞いを調べるための資料となるものだ。Bazメソッドは呼び出し元メソッド(当然アプリケーションを想定する)を信用していない。したがって、このメソッドが採取すべきログは呼び出し元の呼び出し条件を調べるための資料となるものだ。}}最初の呼び出しと次の呼び出しの差は、ライブラリが例外をスローする場合に、暗黙の再スローか明示した再スローかだ。いうか、昨日までは暗黙再スローの存在はまったく知らなかった(10年前には言語仕様を読んでいるから忘れたのだと思うが、覚えていなければ知らないのと同じ)。サーバーサイドではないのでPDBはデプロイ対象としていない状態を想定する。することはできません。することはできません。することはできません。することはできません。することはできません。することはできません。することはできません。することはできません。System以上からわかることは、catchしたExceptionオブジェクトから得られるスタックトレースは、StackTraceプロパティのものであろうがToStringメソッドのものであろうが、併設したtryブロックから先だけだということだ。これはアプリケーション(ライブラリを信用していない)にとっては十分な情報量だ。最低限に必要と考えられる情報(Messageプロパティの値とStackTraceプロパティの値)はすべて単一のToStringメソッド呼び出しで得られる。アプリケーションが例外をログするのであれば、ToStringの結果をログすれば良い(InnerExceptionチェインがnullになるまでToStringすればもっと良い)。それに対して、アプリケーションを信用しないライブラリにとっては話が異なる。信用していないのだから、アプリケーションプログラマに対して、このメソッドの呼び出し(またはそのメソッドを呼び出したメソッド......)はおかしい(引数がおかしいのか、状態がおかしいのか、いずれにしろ事前条件相当のものは例外とは別にログする必要はある)と指摘できなければならない。そのためには、別途スタックトレースを入手する必要がある(Diagnostics.StackTraceとか)。それだけではなく、アプリケーションに例外をスローする場合には次のいずれかを利用すべきということも言える。独自にArgumentException(事前条件のうち引数違反)やInvalidOperationException(事前条件のうち状態違反)を作成し、InnerExceptionにキャッチしたExceptionオブジェクトを設定する。アプリケーションを信用していないのだからInnerExceptionがアプリケーション側でログされることは期待できない。したがって2:のほうが良い。暗黙の再スロー(無引数throw)。キャッチしたオブジェクトを指定した再スローでは真の原因(上の例ではRegexが検出した引数null)の通知元がTargetSiteプロパティにしか残らない。すると、上で示したようにアプリケーションはToStringの結果だけをログするとした場合に、真の原因が不明となりライブラリ側の調査が難しくなる可能性がある。[おお、どうもありがとう。そいつを3番目にして修正かけます。