如何使用Breeze管理器或许在saveChanges失败函数中获取客户端(如sql raiserror级别)的Sql Server数据库trowed错误详细信息。 例如:
// SERVER-SIDE (SQL-SERVER : TRIGGER - After Insert)
RAISERROR ('Espace utilise par Place, Cannot delete.', 16, 1)
ROLLBACK TRAN
RETURN
// CLIENT-SIDE (BREEZE : saveChanges - saveFailed)
var saveChanges = function () {
.....
function saveFailed(error) {
var msg = 'Save failed: ' + getErrorMessages(error);
logError(msg, error);
error.message = msg;
throw error;
}
};
更新1 :好的,将我的breeze版本更新为1.4.1后,我在客户端收到了错误详情,但是:
a)应用程序在服务器端(Breeze控制器Api)停止,在代码低于点的情况下使用InvalidOperationException而没有分配任何调试断点。
[HttpPost]
public SaveResult SaveChanges(JObject saveBundle)
{
return _contextProvider.SaveChanges(saveBundle);
}
b)如果我强行继续,我会在客户端获得Breeze saveChanges saveFailed级别的错误。 如何管理此错误以绕过Breeze服务器端api控制器错误处理程序,但继续在客户端有相关的信息?
在等待足够的答案时,我试图在BeforeSaveEntities范围内报告这些业务规则。但禁止所有使用所有触发器规则代替BeforeSaveEntities将是痛苦的:它们没有相同的功能。
答案 0 :(得分:0)
您是否考虑过使用try / catch重新实现SaveChanges
Web API方法?
您应该能够拦截异常,对其进行分析,并将其更改为您认为适合客户的任何响应。
我想清楚你的问题和答案。如果您不执行任何操作并且Web API方法中存在未捕获的异常,则服务器上的Breeze.NET应转发该错误,BreezeJS会将其转发到saveChanges失败处理程序。这符合你的经验,对吗?
我假设您想拦截服务器上的异常,并且可能为客户端重新设置异常,或者为客户端编写自己的(失败的)响应。为此,我推荐了try / catch。
你有什么样的麻烦“试图用Try / Catch 来装饰服务器端的saveChanges”?我认为应该捕获SQL服务器抛出的异常......但也许不会。执行可能发生在Web API方法之外,在[BreezeControllerAttribute]
(委派给包装Web API [BreezeQueryableAttribute]
的{{1}})的范围内。
这是现在的问题吗?
进一步思考后,try / catch的更好位置可能是[QueryableAttribute]
的自定义(派生)实现中的SaveChangesCore
方法的覆盖:
public class YourCustomProvider : EFContextProvider<YourDbContext> { protected override void SaveChangesCore(SaveWorkState saveWorkState) { try { base.SaveChangesCore(saveWorkState); } catch (System.Exception ex) { // whatever } } }
如果没有捕获它,那么分解就更难以实现,你可以为Breeze.NET提供一个很好的参数,以便在EFContextProvider
的范围内提供异常处理钩子。
作为一种解决方法,您可能必须重新实现[BreezeQueryableAttribute]
(它是开源的)为您自己提供该挂钩。如果你这样做...并且它运作良好...请发送给我们(克隆/分叉/拉取请求),以便其他人可能受益。当我们有片刻时,我们也会独立调查。