7

私はこれまでServiceStackを使用しており、エラーの処理が一見難しいことを除けば、すばらしい結果が得られています。メッセージのシリアル化中に問題が発生した場合（たとえば、デフォルトのコンストラクターをメッセージに追加するのを忘れたため）、クライアントに返されるのは、サーバーに内部エラーとステータスコード500があったというメッセージだけです。 Global.asaxのHttpApplication.Errorイベントは、ヒットしないため機能しません。どちらもしませんApplication_Error。これはエンドユーザーのシナリオには不十分であるだけでなく、問題の原因を特定する唯一の方法はクイックウォッチのこの醜い表現であるため、これらのエラーのデバッグは非常に面倒です。

Encoding.Default.GetString( ((System.IO.MemoryStream)((SyncMemoryStream)((System.Net.HttpWebResponse)(((WebException)ex).Response)).ResponseStream))._buffer)

私が欲しいのは、サーバー側のすべてのエラー（ServiceStackによるシリアル化、またはサービスのエラー）をキャッチし、Errorsすべてのメッセージタイプが持つコレクションに必要な情報を追加することです。

4

1 に答える 1

11

ServiceStackでのエラー処理と検証の詳細については、ServiceStackの検証とエラー処理のwikiページを参照してください。

現時点では、カスタムロジックでシリアル化例外を処理する方法はありません（ただし、TODOリストに追加します:)。

Response DTOにResponseStatusプロパティがある場合（つまり、IHasResponseStatusから継承する場合）、ServiceStackは例外を自動的にシリアル化する必要があります。

また、StackTraceをシリアル化するには、AppHost.Configure（）オンロードスクリプトのSetConfig（）を使用してDebugModeをtrueに設定します。

于 2011-01-25T13:47:23.037 に答える