在 OpenRasta 处理程序中处理异常时，转换为响应的最佳方法是什么？
我正在使用 OpenRasta 2.0 构建 REST API，它的可扩展性非常棒 - 例如，我们已经成功地使用 DotNetOpenAuth 相当轻松地插入了 OAuth 身份验证。
然而，我现在已经到了需要定义错误条件响应的地步。我们正在采用有关 HTTP 错误代码的标准 - 但我也意识到返回有意义的响应，就像 Twitter（REST 的常年示例）所做的那样：
{
"error":"This method requires authentication.",
"request":"\/1\/statuses\/followers.json"
}
是从我们所有处理程序返回 OperationResult 的最佳方式，手动捕获异常并映射到 ResponseResource？在我看来，与 OpenRasta 的其他功能相比，这似乎是相当大的开销。
或者我们应该编写某种贡献者来捕获管道中抛出的异常并全局处理问题？也许只翻译特定类型的异常（RestException？）。
基本上，我正在寻找最佳实践是什么以及其他人如何处理它的感觉。
谢谢。
编辑：
今天看了一段时间后，我无法弄清楚如何包装处理程序调用 - 我已经声明自己是一个OperationInterceptor派生类，并使用ResourceSpace.Uses.CustomDependency 但无论在哪个我尝试并包装在 try-catch 中的方法，异常仍然冒泡。
RewriteOperation、BeforeExecute 还是 AfterExecute 是最合适的陷阱位置 - 如果是这样，您能给我一个关于如何捕获的线索吗？开始？
谢谢。
I'm using OpenRasta 2.0 to build a REST API and its extensibility is fantastic - we've managed for instance to plug-in OAuth authentication using DotNetOpenAuth fairly painlessly.
However I've come to the point now where I need to define our responses for error conditions. We're adopting the standards regarding HTTP error codes - but I'm concious of returning meaningful responses as well, pretty much like Twitter (the perennial example of REST) does:
{
"error":"This method requires authentication.",
"request":"\/1\/statuses\/followers.json"
}
Is the best way to return an OperationResult from all of our handlers, manually capture exceptions and map to a ResponseResource? This seems to me to be a fair amount of overhead compared with how the rest of OpenRasta functions.
Or should we write some kind of contributor to capture exceptions thrown in the pipeline and globally handle the issues? Perhaps translating only exceptions of particular types (RestException?).
Basically I'm after a feeling for what the best practice for this would be and how others have handled it.
Thanks.
EDIT:
After looking at this for some time today I'm having trouble figuring out how to wrap the handler call - I've declared myself a OperationInterceptor derived class and have hooked that into the pipeline with ResourceSpace.Uses.PipelineContributor<OperationInterceptorContributor>() and set a custom dependency up ResourceSpace.Uses.CustomDependency<IOperationInterceptor, ExceptionHandlerInterceptor>(DependencyLifetime.PerRequest) but no matter in which of the methods I try and wrap in a try-catch, the exception still bubbles.
Is it RewriteOperation, BeforeExecute or AfterExecute that is the most appropriate place to trap - and if so can you give me a clue as to how to start?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以采取一些措施来实现您想要的目标。
首先，您可以构建一个 IOperationInterceptor，它将对处理程序的调用包装在 try/catch 块中，并在 ICommunicationContext 上分配正确的 OperationResult。
然后，如果您希望将其序列化为 json，则需要将操作结果的 ResponseResource 属性分配给描述错误的类型（现在我们将其称为“TitsUpResource”）。
最后，将该类型注册为没有 URI 的资源，这样您就可以向其中添加 json 编解码器
ResourceSpace.Has.ResourcesOfType().WithoutUri.TranscodedBy 或您可能想要的任何其他内容。
There's a couple of things you can do to achieve what you want.
First, you can build an IOperationInterceptor that wraps the call to your handler in a try/catch block, and assign the correct OperationResult on the ICommunicationContext.
Then if you want this to be serialized in json, you'll want to assign the ResponseResource property of your operationresult to a type that describes your error (let's call it "TitsUpResource" for now).
Finally, register that type as a resource with no URI, so you can add the json codec to it
ResourceSpace.Has.ResourcesOfType().WithoutUri.TranscodedBy or whatever else you may want.