删除数据库中不存在的记录时无法捕获 org.hibernate.StaleObjectStateException
我的应用程序有一个删除用户选项。现在为了检查并发条件，我尝试了以下用例，
- 在 Chrome 和 Firefox 浏览器中打开了应用程序。
- Firefox 中已删除的用户
- 现在尝试在 Chrome 浏览器中删除同一用户，我收到异常
org.hibernate.StaleObjectStateException..这是正确的..因为我试图删除一个不存在的对象。但我无法捕获这个异常
try{
getHibernateTemplate().delete(userObj);
} catch (StaleObjectStateException e) {
e.printStackTrace();
}
我如何捕获这个异常？
My application has a delete user option. Now in order to check concurrency condition I tried the following use case
- opened application in chrome and firefox browser.
- deleted user in firefox
- now trying to delete the same user in chrome browser I get exception
org.hibernate.StaleObjectStateException.. which is right .. since I am trying to delete an object which doesn't exists. But I am not able to catch this exception
try{
getHibernateTemplate().delete(userObj);
} catch (StaleObjectStateException e) {
e.printStackTrace();
}
How do i catch this exception ??
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您将无法在那里捕获它，因为抛出异常的不是删除调用，而是会话的刷新，这会在稍后发生（在执行查询之前或在事务提交之前）。
无论如何你不应该捕获这个异常，因为当 Hibernate 抛出异常时，你不能再继续使用会话：它处于不稳定状态。应用程序中唯一可以捕获此类异常的部分是在事务之外，以便向用户显示错误消息（或重试，但在这种特殊情况下这是不可能的）。
You won't be able to catch it there, because it's not the delete call that throws the exception, but the flush of the session, which happens later (before the execution of a query, or before the transaction commit).
You should not catch this exception anyway, because when Hibernate throws an exception, you can't continue using the session anymore: it's in an unstable state. The only part of the application where such an exception can be caught is outside of the transaction, in order to display an error message to the user (or retry, but this won't be possible in this particular case).
您正在捕获 StaleObjectStateException 而不是 StaleStateException :-)
更新：
查看堆栈跟踪；假设您正在处理事务，则只有在提交事务时才会引发异常。
You are catching StaleObjectStateException instead of StaleStateException :-)
UPDATE:
have a look at the stacktrace; assuming you're working in a transaction the exception might only be thrown when the transaction is committed.
您问题中的代码表面上看起来很正确。
如果该删除调用在执行时实际上抛出该异常，那么您的代码将捕获它。如果没有，那么异常实际上是在不同的地方抛出的……或者抛出的异常是不同的。
我会暂时将catch替换为
java.lang.Throwable的catch，以查看此时是否正在传播其他异常。并添加跟踪打印以查看代码是否正在执行。如果您已经有堆栈跟踪，它将告诉您异常在哪里抛出，除非发生了非常棘手的事情。您只需要在堆栈中进一步捕获它即可。
The code in your question looks right on the face of it.
If that delete call actually throws that exception when executed, then your code will catch it. If it doesn't then the exception is actually being thrown in a different place ... or the exception that is being thrown is a different one.
I'd temporarily replace the catch with a catch of
java.lang.Throwableto see if some other exception is propagating at that point. And add a trace print to see if the code is executing at all.If you already have a stack trace, that will tell you where the exception is being thrown unless something really tricky is going on. You just need to catch it further up the stack.