WR blog

エラーの分類とエラーハンドリング戦略

エラーの種類を簡単に。

* ビジネスロジックエラー(代替フロー)
* システムエラー
* 入力エラー
* プログラミングエラー
* 内部状態不整合エラー
* (他にある?)

### ビジネスロジックエラー
* ユースケースにおける、いわゆる代替フロー。

* 残高1000円なのに、2000円引き出そうとしたときの処理フローに相当
* 機能定義・論理設計・基本設計段階で洗い出される必要がある。
* 機能の一部として、エラー発生時の処理が明確に洗い出されている必要がある。
* アプリケーションは、エラー内容に応じた処理を実行するように実装されている必要がある。

### システムエラー
* 動作環境などが正常に動いていない場合のエラー

* ATMシステムで、ATMとバックエンドシステムのネットワークが疎通していない場合や、バックエンドシステムにおいて、RDBMSが動作していない場合などに相当
* 基本設計・詳細設計段階で洗い出されている必要がある。
* 要件にも依存するが、致命的エラーであることをユーザーに通知できれば良い。エラーの種別毎に処理を行うなどは求められないケースが多い。
* 適切に不具合情報を入れ込んだロギングが重要。
* 2重化など、システムエラーが起こる原因自体を排除するor発生頻度を低める取り組みについては、ここでは触れない。

### 入力エラー
* いわゆるvalidationエラー。入力したデータが、まずい場合

* (機能定義・)論理設計・基本設計段階で洗い出される必要がある。
* 金額入力欄にアルファベットが入力された場合など
* (ビジネスロジックと同様?)

### プログラミングエラー
* API・クラスライブラリ・フレームワーク・ユーティリティクラスを適切に使用していないために生じるエラー。

* 基本的に、詳細設計・プログラミング作業中にしか発生しない。
* 結合テストにおいてこのエラーの発生する可能性を可能な限り低めるような努力がなされていなくてはならない。
* DAOにConnectionをsetせずにfindXXX()メソッドを呼んだ場合など

### 内部状態エラー
主に2種類あると考える（もっとあるかも）

* システムが保持するデータの不整合
* マスタ不一致エラーとか
* 主に運用のミスによる
* プログラムのロジックバグにより、満たされているべき前提条件が満たされなくなったため発生するエラー
* たいていの場合DAOにConnectionがキチンと設定されるが、特定の処理を実行するとDAOにConnectionが設定されなくなり、nullPointerExceptionが発生する
* 設計・テスト段階で洗い出しに失敗したプログラミングエラーが顕在化したケースと考えることが出来る。

* 要件にも依存するが、致命的エラーであることをユーザーに通知できれば良い。エラーの種別毎に処理を行うなどは求められないケースが多い。
* 適切に不具合情報を入れ込んだロギングが重要。
* (システムエラーと同様?)

### フェーズとエラー種別とエラーハンドリング

フェーズとエラー種別により、適切なエラーハンドリング戦略は異なる。
プログラミングフェーズで好ましいエラーハンドリングと、保守・運用フェーズで好ましいエラーハンドリングは異なる。そもそも出るエラーの特性がまったく異なるのだから、乱暴な比較ではあるのだけれども。

すくなくとも、エラーハンドリングの目的が、「機能仕様を満たす」ことか、それとも、次のアクションを起こしやすくするための単なる「情報提供」か、で、求められる戦略が異なる点は留意したほうが良い。

### ツッコミは愛をこめて。

artonさんの日記のやりとりに刺激されて、妄想含みで書いてみた。乱文失礼。

ホリエモンの錬金術

dkirokuでURLを見かけたので再度よむことにしてみた。

サマライズもしくは気になった箇所を抜粋する。
そして、自分の勉強のため出てきた用語をまとめてみる。

### [ホリエモンの錬金術 ?４　（フォレスト・コンサルタンツ – 山根治blog）](http://consul.club.or.jp/item/275)

ホリエモン・マジック・ショーの3つのトリック

* 光通信とかグッドウィルとか大和証券ＳＭＢＣを仲間に引き入れた
* 通算３万分割にも及ぶ株式分割と、２回にわたる公募増資
* 決算数字のお化粧

決算数字のお化粧について

* 正体不明の仕掛品(565百万円の仕掛品; 第9期（平成16年9月期）単体;経常利益（単体）1,410百万円の38％に相当)
* 第８期に計上されていた貸倒引当金の大幅取り崩しによる、特別利益（貸倒引当金戻入額）の計上(141百万円)
* 46億円余りの無形固定資産の計上(第9期の連結B/S;4６億円)と、その大半が過年度には経費として発生年度に一括処理
* 資産性に乏しい企業の買収による、営業権（1,121百万円）と連結調整勘定（2,408百万円）の計上
* とか

### ホリエモンの錬金術 ?６　（フォレスト・コンサルタンツ – 山根治blog）
> 堀江さんは平成８年４月に、有限会社オン・ザ・エッヂを設立し、代表取締役に就任します。出資金６００万円は、有馬晶子さん（現、株式会社クリアキューブ代表取締役）の父有馬純一郎さん（当時、ブルテルインターナショナル株式会社代表取締役）からの借入金で賄ったようです。社員は、堀江貴文、有馬晶子、有馬純一郎の三名。

当時は、1株5万円。

### ホリエモンの錬金術 ?７　（フォレスト・コンサルタンツ – 山根治blog）
> 一株３００万円という異常に高い価格で第三者割当増資を行なったのです。平成１１年９月４日に、株式会社光通信へ１５０株、同年９月３０日に、株式会社グッドウィル・コミュニケーションへ５０株。会社には、それぞれから４５０百万円（３００万円×１５０株）、１５０百万円（３００万円×５０株）入金。資本として入ってきた６億円は、資本金と資本準備金に半分ずつ振り分けられています。

### ホリエモンの錬金術 ?８　（フォレスト・コンサルタンツ – 山根治blog）
> この時に３億６千万円（３００万円×１２０株）という購入資金は実際には動いている形跡がありませんので、この取引そのものが架空のものである可能性が高いのです。
> 　何故このような小細工がなされたのでしょうか。それは、前回指摘した一株３００万円という、額面の６０倍にもつり上げた会社の株価を、いかにも現実らしく装うためであると考えられます。つまり、共同経営者である有馬晶子さんの株式を一株３００万円で購入したように見せかけて、一株３００万円という評価額が現実的なものであるかのように世間を欺いているらしいです。

1株300万円の価値があるように見せかけた。

> 平成１１年１２月１７日、堀江さんは、大和証券エスビーキャピタル・マーケッツ株式会社（現、大和証券ＳＭＢＣ）と株式会社光通信パートナーズに対して、持株７００株（５８０株＋１２０株）のうちから、それぞれ、３０株と１０株とを譲渡しています。一株３００万円、総額はそれぞれ、９，０００万円と３，０００万円。この譲渡についても、同じ（注５）が付けられ、「資金調達を目的とする発行」と虚偽の記載がなされています。この二者に対する株式譲渡は、ホリエモン・トリック（評価のつりあげ）のいわばアリバイ作りに使われたと思われるものです。

上と同様。

> この時会社は、資本準備金を取り崩して資本に組み入れると同時に、１：１２の株式分割を実施しています。その後矢継早に、法外な株式分割が４回も繰り返されるのですが、その第１号となるのがこのときの株式分割（１株を１２株に分割）なのです。この株式分割こそ、ホリエモン・マジックの第三のカードです。

300万円にかさ上げした株価を分割して、1株あたりの価格を下げた。

> 　平成１２年４月６日、マザーズ上場。会社は上場時に、１，０００株を公募価格６００万円で売り出します。この評価額（公募価格）６００万円は、１２分割後の評価額２５万円の２４倍に相当します。

> 場初日は、相場全体の地合いが悪く、公募価格の６００万円を２５％下回る４５０万円の売り気配で引けています。翌４月６日に４４０万円の初値がつき、２６３株の出来高で終わっています。

大和証券ＳＭＢＣと、光通信パートナーズは、5万円のライブドア株の価値を300万円とかさ上げする片棒を担ぐ代わりに、(440万円 x 12 – 300万円) x 株数の儲けを得た(or得る権利を得た)。

### ホリエモンの錬金術 ?９　（フォレスト・コンサルタンツ – 山根治blog）
> 　この５年間ライブドアは、まともな収益構造を持っておらず、赤字をタレ流しています。その赤字幅を縮めているのがＩＰＯ（新規上場）を支援するという名目でなされているインチキ上場システムです。

ここがよくわからない。

> それにしても、５年の間に３６万分割を敢行するなど、あきれてものが言えません。株価操作がみえみえのこの破廉恥な行為が、本当に適法と言えるのでしょうか。しかも、その最大の受益者が、会社の筆頭株主であるホリエモン自身なのですから。分割とセットになった増資をするたびに、ホリエモンの資産が自動的に増える仕組みになっているのです。

買う株主がいるから、ホリエモンはさらに肥える。

### 追記 2005/05/19
一概に言えないと思うし、自分も良くわかっていないので差し引いて考えてほしいのだけど、
【一般に】一般公募による増資は既存株主の利益を損ねる。
なぜなら、株の流通量が減る増えるため既存の株の価値を下げるから。
既存の株主の持ち株比率を下げるから。

ただし、資本量が増えるため、投資額を増やすことが可能になる。
よって、流通量の増大による価値の低下と、資本量増大にともなう追加投資による利益増加見込みのトレードオフの関係にあるといえる。
ゆえに、再投資を効率的に行うことができなかった場合、株価が低下して、既存株主の利益を損ねる。
ただ、如何に再投資を効率的に行っても、既存の株主の持ち株比率が下がってしまう。

しかし、株式分割を行いながら、増資を行うことで、

* 既存の株主の持ち株比率を下げることなく
* 増資にともなう株価低下を避ける

ことができた。と、整理。

#### 用語
* 連結調整勘定 : B/S上の純資産(資産-負債)よりも実際の価値が高い場合の差額を計上する勘定科目
* CyberSeminar – 連結経営 > 3:連結会計の基礎（その2） – GLOVIA
* 中央青山監査法人 > Web-CAN
* 会計の話
* 第三者割当増資:
* 第三者割当増資
* Ｑ＆Ａ株式公開よくあるご質問
* 現物出資
* 現物出資（金銭以外の財産での出資）

XAエミュレート対象となるリソースマネージャの扱い

from S2.2.9 リリース – koichikのひとりごと
> 例えば XA に対応した Oracle (Oracle が提供する XADataSource を使用する) と対応していない HSQLDB (S2 が提供する XADataSource で XA をエミュレートする) を同一のトランザクション中で更新する場合，最初に HSQLDB からコネクションを取得することで，二つの DB がどちらもコミットされるかどちらもロールバックされるかという原子性 (ACID の A) が実現できます．

なるほどーそういうことか。理解できました！ありがとうございます！ koichikさん。

### 昨日の質問
昨日のJ2EE勉強会(仮)で、以下の質問をさせていただいた。（若干、わかりやすく整理しています。昨日はもっと要領を得ない質問な感じ（苦笑）でした。）

> S2JTAの枠組みの中で、XA非対応のリソースマネージャを扱う場合、XAをエミューレートするラッパ経由で扱うことになるようだが、その場合、
>

XA非対応のリソースマネージャ1つがJTA配下のトランザクションに参加している場合、1フェーズコミットプロトコルを使用する
>
XA対応のリソースマネージャ1つの場合、通常の1フェーズコミットプロトコルを使用する
>
XA対応のリソースマネージャ2つ以上の場合、2フェーズコミットプロトコルを使用する
>

> という理解でよいか？

なるほど、S2JTAの実装はLast Resource Commit Optimizationの機構を持っているため、
1番目、2番目の内容は正しいようだ。ただ、koichikさんの日記にかかれてあるように、

> Last Resource Commit Optimization は，このように複数のリソースがある場合に，最後のリソースに対しては prepare ではなく，通常の 1 フェーズコミットを指示するというものです．

というわけで、XA対応のリソースマネージャが2つある場合、すべてのリソースマネージャに対して2フェーズコミットプロトコルでコミットするわけではないということみたいである。
だから、3番目の内容はちょっと正しくない。なるほどなるほど。

J2EE勉強会(仮)

J2EE勉強会(仮) – ひがやすを blog

参加してきた。

内容は、

* Seasar2のJTA実装、コネクションプール実装をソースコード中心に追っかける
* JSFの特徴・アーキテクチャをPPTで説明する

でした。説明はすべてひがさん。お疲れ様でした＆ありがとうございました。

Continue reading J2EE勉強会(仮)

リアルタイム・システムの構造化分析　リアルタイム・システムの仕様書作成手法

* リアルタイム・システムの構造化分析　リアルタイム・システムの仕様書作成手法 – 電脳書房在庫目録

昔から読んでみたく思っていたのだけど、いまさら・・・・って感じだな。高いし。

なぜ読みたいと思っていたのか？というと、分析のためのツールキットはたくさん持っていたほうがよいと考えるから。
コンサルタントが経営分析などのテンプレートをたくさん用意しているように、
設計者・分析者はソフトウェアの分析のためのある程度のツールキットを用意すべきと考えるから。

ほんたったがほしいがいじんさん

仕事を終えてから、明日のズラ会に備えてファミレスでJava Transaction Processingを読んでいた。
いつもと同じように、X31と書見台：ほんたった、ポストイットがお供。
そして、本の内容や目次、不明な用語などをExcelにまとめつつ、読み進めた。

この本の対象はトランザクションという分野であるため内容が多少概念的だし、英語で書かれているから、読むのにちょっと時間がかかる。今日は無理に読み進めることはせず、JDBCとXAResouceの関係、JTAの代表的なインタフェースであるUserTransaction, TransactionManager, Transactionの関係と、UserTransactionとTransactionManagerの相違点に触れている箇所を抜粋して読んだ。
これらの位置づけを大体理解したので、明日のズラ会で不明な点、理解があいまいな点がクリアになることを期待しようかなと。

さて、本題。

自分は、よくファミレスで本を読むのだけど、そのときは、

* Thinkpad X31をたたきながら、
* 本を書見台：ほんたったに載せて、
* ポストイットを手元に置いて

という感じでやっている。結構大掛かりな感じであって、ちょっと目立つ。でも便利なので、気にしないことにしている。

当然、今日もこんな感じでやっていた。

今日は遠くから熱い視線を感じる・・・。と思ったら、遠くの席の外人さんにチェックされているようだ。
そんなに物珍しいかね？
ま、気にせずに本を読んでいたのだけど、2時になったので帰宅することにした。
レジに向かう途中、その外人さんが近寄ってきて、たどたどしい日本語で・・・

Continue reading ほんたったがほしいがいじんさん

Java Transaction Processing

さて、土曜日までにどこまで読めるかなー

構造化分析・プログラミング – ひがやすを blog

先に取り上げた、いがぴょんさんのエントリに対するひがさんのコメントと、実装スタンス。

> OCPを守るために、くーすでどうしているかというとロジック(メソッド)は常にインターフェース経由で呼び出すようにします。あるロジックが別のロジックを呼び出す必要があった場合、DIコンテナによってロジックオブジェクトをDIしてもらい、それを利用するのです。

文章だけだと、やっぱりわからない部分が残る。しょうがない。

ただ、外から見ていると、なんとなく、立ち位置や価値観が違うところもあれば、単に表現上の問題でミスマッチがおきているところもあるように感じられる。
もちろん、これは単なる勘だけど。

### 感謝したい。
あらためて思うのだけど、こういうやり取りを直接読めること、そのものに感謝したい。

少し前は、第一線で活躍する一流デベロッパの意見を聞くことは非常にむずかしかった。イマイチ信用してよいのかどうかわからない専業ライターさんと、何をたくらんでいるのかわからないエバンジェリストもしくは社長さんぐらいからしか、情報を得ることができなかった。

われわれは幸せな時代にすんでいる。
第一線で活躍する一流デベロッパのソースを読み、開発に対する考えを聞くことができるのだから。

Javaメモリモデル

職場で設計に関する議論があり、自分がJavaのメモリモデルを理解していないことを痛感させられた。
というわけで、

* Javaの理論と実戦: Javaメモリ・モデルを修正する　第1回
* dW : Java technology : Javaの理論と実戦: Javaメモリ・モデルを修正する　第2回
* Java言語規定スレッド及びロック

などを読んで学習。メインメモリとローカルメモリの同期をとることが肝要と理解した。

Java言語仕様は、メモリモデルと呼ばれる、いわゆるRAM、キャッシュ、レジスタなどなどから構成される実際のマシンのメモリを適切に抽象化したモデルを用い、そのモデルがどのような要件を満たさねばらないか？を規定している。あくまでもモデルに対する要件のみを規定しているため、実際のマシンアーキテクチャから、比較的独立性を確保することができる。という仕組みになっているようだ。誰が考えたか知らないが、うまい仕組みだ。モデルの適切な定義・モデルの適切な利用と感じられる。

さて、この作業を通じて改めて思うのは、Whatを正しく知るためにはHowを知らなくてはならないということである。ある概念を、自然言語や類似の概念でいくら説明されても、詳細は理解できない。「それがどうやって実現されるか」を知らなくては、概念をキチンと理解できないのだ。

この例でいうと、プログラミング言語がどのような機能性を果たしているかを説明するためには、プロミング言語の処理がどのように実行されるかを知らなくてはならないということになる。

ただ、このWhatとHowの関係で注意していただきたいのは、Howを説明するときに使用する下位の概念の抽象度・詳細度である。
Howはある下位の概念を用いて記述されなければならず、かつ、問題を説明するのに適切なレベルで詳細な概念を用いて説明しなくてはならない。Howを説明する際に用いた概念が詳細すぎては、Howが複雑になりすぎて、Whatを理解することが難しいことは容易に理解できるだろう。

What -> How -> What -> …

無限ループ・・・。

オチはない。

2005/05/09 日記: オブジェクト指向レス開発

> 「良くない設計」や「良くない実装」をしてしまわないための一番の近道は、「構造化分析手法」の適用だと考えています。基本的に規模が大きければ大きいほど、携わる人間が多ければ多いほど、そして仕様変更が入る確率が高ければ高いほど、構造化分析および構造化プログラミングがなされていないと手詰まりになります。「失敗オブジェクト指向」にしてしまわない近道の一つは、「構造化」の導入であると私は確信しています。というか、そもそもオブジェクト指向においても「構造化」にまつわる概念は存在しているのですが、多くの文献や記事においては「構造化手法」の側面はかなり薄っぺらくしか扱われていないように考えます。その実例として Java言語のパッケージ構造についての現実的な利用についての話題をほとんど書籍や雑誌で見かけないことから現れています。(現実的な現場の多くでは適切に運用されているのですけれども…)
>
> そしてもう一つ重要なポイントなのですが、オブジェクト指向やデザインパターンのなかの多くの技は「構造化」という観点からはリレーショナルデータベースにおける「逆正規化」に相当しているのだという点です。残念なことに、多くの人に、この点もあまり理解されていません。オブジェクト指向はほんとうに注意深く導入しない限り、プログラムの理解を妨げ、試験をしづらくし、生産性を下げ、保守性を下げます。オブジェクト指向は間違いなく「逆正規化」に相当します。そもそもオブジェクト指向やデザインパターン適用について、これらが生産性や保守性に与える効果についての統計的な情報にほとんど出会わないことについても、これは悲しい現実であると受け止めています。

興味深い。いがぴょんさんの考え方・設計、（フレームワークより上位のアプリケーションレイヤにおいて）デザインパターンなどを駆使したいわゆるオブジェクト小僧の設計のどちらが100%間違っていて、どちらが100%正しいという問題ではないと理解している。どちらも、厳密な意味での論理性をもたない。

ただ、いがぴょんさんのおっしゃられていることは、皮膚感覚として理解できるし、
概念的なレベルでは納得ができる。
（段階的詳細化の考えに裏付けれた意味での）構造化技法は、数ある構造化の仕組みの中でもっともシンプルでパワフルである。ツリー構造＋概要→詳細方向の段階的詳細化。
（継承、包含、利用、抽象型などの考えに裏付けられた意味での）構造化技法であるオブジェクト指向技法は、パワフルであるがシンプルではない。複雑である。

シンプルなパラダイムは表現力が少なく、すくなからず制約を持つが、形式的に扱いやすい。人間によって理解がしやすく、文脈的な影響も排除できる。
リレーショナルモデルも同様。

### 逆正規化

個人的には、

> オブジェクト指向は間違いなく「逆正規化」に相当します。

の論理的な説明が聞きたいなぁ。

ところで、いがぴょんさんの日記って、トラックバック打てるのかなぁ？