3

データベースクエリなどの潜在的なランタイム障害に関してはEither[String, Option[T]]、次の結果を正確にキャプチャするために、何らかの形式を使用する必要があるようです。

  1. 一部（レコードが見つかりました）
  2. なし（レコードが見つかりません）
  3. SQL例外

オプションには単に十分なオプションがありません。

私はscalazに飛び込む必要があると思いますが、上記の何かが欠けていない限り、今のところそれはまっすぐです。

DAOの実装で自分自身を追い詰め、書き込み操作にどちらかを使用しましたが、一部のどちらかの書き込みはオプションの読み取りに依存していることがわかりました（たとえば、新しいユーザーのサインアップ時に電子メールが存在するかどうかを確認する）。 。

どちらかにオールインする前に、成功/失敗/例外のランタイムトリフェクタを処理する方法について誰かが別の解決策を持っていますか？

4

3 に答える 3

8

Box素晴らしいliftフレームワークからお試しください。それはまさにあなたが望むものを提供します。

詳細については、このwiki（および上部のリンク）を参照してください。幸いなことに、リフトプロジェクトは十分にモジュール化されており、使用する依存関係は次のとおりBoxです。net.lift-web % lift-common

于 2012-07-15T00:48:39.760 に答える
5

Option[T]ケースrecords foundに使用し、 no records foundSQLExceptionの場合は例外をスローします。

PersistenceException漏れのある抽象化がないように、例外を独自の例外タイプ内にラップするだけです。

予期しないデータベース例外から回復することはできず、回復したくないので、このようにします。500 Internal server error例外はトップレベルでキャッチされ、そのような場合、Webサービスはを返します。

回復したい場合はValidation、Liftによく似たscalazから使用しBoxます。

于 2012-07-15T17:16:13.617 に答える
0

これが私の改訂されたアプローチです

どちらかを返すクエリ書き込み操作を保持します（左の結果を理解するためにロールバックするトランザクションブロックに役立ちます）。

ただし、オプションがクエリの読み取りを返す場合、例外をNoneで飲み込む（そしてログに記録する）のではなく、500エラー画面を作成して、例外をバブルアップさせました。

クエリ例外などのランタイムエラーを処理するときに、デフォルトでどちらかの結果タイプを処理しないのはなぜですか？Option [T]読み取りは、Tに到達するためにフォールド/マップする必要があるEither [Why-Fail、Option [T]]と比較して、操作が少し便利です。これがアプリケーションの現在のセットアップ方法であるため、リファクタリングは必要ありません;-)）

必要なその他の変更は、AJAXリクエストのみです。500エラーページの応答全体をAJAXステータスdivコンテナに表示するのではなく、ステータスタイプを確認し、それに応じて500エラーメッセージを表示します。

if(data.status == 500) 
  $('#status > div').html("an error occurred, please try again")

おそらく、応答を送信する前にサーバー側でisAjaxチェックを実行できます。その場合、エラーページ自体ではなく、ステータス+メッセージのみを返送できます。

于 2012-07-16T15:45:10.280 に答える