Web APIカスタムExceptionオブジェクトを基底例外に変換します

Question

Web APIを使用して新しいWebアプリケーションを開発する際、トランザクションの結果を格納できる一連の基本的な "応答"クラスを作成することをお勧めします将来のいかなる警告、エラー、またはその他の必要なデータであってもかまいません。以下のサンプル：この応答オブジェクトに縛ら

public class VoidResultsVM 
{ 
    public bool IsSuccess { get; set; } 
    public List<string> Results { get; set; } 
    public List<Error> Errors { get; set; } 
    public List<Alert> Alerts { get; set; } 

    public VoidResultsVM() 
    { 
     Results = new List<string>(); 
     Errors = new List<Error>(); 
     Alerts = new List<Alert>(); 
    } 
} 

は、.NETでのExceptionクラスから派生したカスタム例外オブジェクトのリスト（「エラー」）です。これらのクラスの主な利点は、エラーが発生した場所を正確に特定でき、ユーザーにカスタムメッセージを追加してエラーを説明できることです。以下の例は：

public class Error : Exception 
{ 
    //public Exception Exception { get; set; } 
    public string Origin { get; set; } 
    public string UserMessage {get; set;} 
    private DateTime timeStamp; 
    public DateTime TimeStamp { get { return timeStamp; } set { timeStamp = DateTime.Now; } } 
    public string Resolution { get; set; } 


    public Error(string msg, Exception ex, string origin, string usermessage, DateTime @timestamp, string resolution = "") 
     :base(msg, ex) 
    { 
     Origin = origin; 
     UserMessage = usermessage; 
     TimeStamp = @timestamp; 
     Resolution = resolution; 
    } 
} 

このオブジェクトは、既に開発し、アプリケーションのバックエンドをデバッグする上で極めて有用であったと私はそれを可能な限り維持するために探しています。

私が実行している問題は、これらの「エラー」オブジェクトのいずれかが返された場合、Web API（私はそう考える）がその「エラー」オブジェクトを例外の基本クラスに変換していることです。 APIからJSON出力については、以下を参照してください：

{ 
    "IsSuccess": false, 
    "Results": [], 
    "Errors": [{ 
     "ClassName": "App.Models.Error", 
     "Message": "Error getting history", 
     "Data": { 

     }, 
     "InnerException": { 
      "ClassName": "System.Exception", 
      "Message": "No records found for criteria", 
      "Data": null, 
      "InnerException": null, 
      "HelpURL": null, 
      "StackTraceString": " at App.Database.DatabaseCore.GetHistory(HistorySearchVM history)", 
      "RemoteStackTraceString": null, 
      "RemoteStackIndex": 0, 
      "ExceptionMethod": "8\nGetShipmentHistory\nApp.Database, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null\nApp.Database.DatabaseCore\nApp.Models.ViewModels.VoidResultsVM GetHistory(App.Models.ViewModels.HistorySearchVM)", 
      "HResult": -2146233088, 
      "Source": "App.Database", 
      "WatsonBuckets": null 
     }, 
     "HelpURL": null, 
     "StackTraceString": null, 
     "RemoteStackTraceString": null, 
     "RemoteStackIndex": 0, 
     "ExceptionMethod": null, 
     "HResult": -2146233088, 
     "Source": null, 
     "WatsonBuckets": null 
    }], 
    "Alerts": [] 
} 

だから私の質問はこれです：背中に投稿するときのWeb APIは、基本クラスに戻って、それを変換しないように、どのように私は私の「エラー」クラスを変更することができますクライアント？これはオーバーライドすることすらできますか？

EDIT以下

は、このオブジェクトを作成して返すためにAPIコントローラおよびデータベースからのコードです。 Exceptionオブジェクトへまたはからエラーオブジェクトを変換するコードにはロジックがありません：

APIコントローラ

public VoidResultsVM Search(SearchVM vm) 
    { 
     DatabaseCore db = new DatabaseCore(); 
     VoidResultsVM results = new VoidResultsVM(); 
     try 
     { 
      if (ModelState.IsValid) 
      { 
       results = db.GetRecordById(vm.Id); 
      } 
      else 
      { 
       throw new HttpResponseException(Request.CreateResponse(HttpStatusCode.BadRequest)); 
      }; 
     } 
     catch (Error) 
     { 
      throw new HttpResponseException(Request.CreateResponse(HttpStatusCode.BadRequest)); 
     } 
     catch (Exception) 
     { 
      throw new HttpResponseException(Request.CreateResponse(HttpStatusCode.BadRequest)); 
     } 
     db = null; 
     return results; 
    } 

データベース

public Record GetRecordById(int id) 
    { 
     Record i = null; 
     using (var transactionScope = TransactionScopeBuilder.CreateReadCommitted()) 
     { 
      AppContext tempContext = null; 
      try 
      { 
       using (tempContext = new AppContext()) 
       { 
        i = tempContext.Records.Where(x => x.Id == id).FirstOrDefault(); 
       } 
      } 
      catch (Exception ex) 
      { 
       Common.Common.Log("", logName, Common.Common.LogLevels.ERROR, ex); 
       throw new Error(ex.Message, ex, "DATABASE", "", DateTime.Now); 
      } 
      finally 
      { 
       transactionScope.Complete(); 
      } 
     } 
     return i; 
    } 

Answer 1

数ソリューションを通じて働いた後、私がすることにしました最もデバッグ用途のある追加の情報を保持する専用のビューモデルを返し、完全なエラーモデルのみを記録するというマイケルの提案に従ってください。