何时使用 JDBC 对连接、语句和结果集调用 getWarnings()?

发布于 2024-11-16 16:48:02 字数 688 浏览 1 评论 0原文

在 JDBC 中,ConnectionStatementResultSet 类型各自都有一个 getWarnings() 方法,指定该方法生成与该类型的对象关联的第一个警告。第二个和后续警告(如果存在)会链接到第一个警告(如果存在,则在没有警告的情况下会生成 null)。

规范称,在执行某些操作后,与这些类型的对象相关的警告将被清除。例如,读取每个新行时,ResultSet 上的警告将被清除。

SQLWarning 类型是SQLException 的子类型。那么警告的存在是否会由异常表明?如果异常的运行时类型是 SQLWarning,那么该异常是否会链接到关联的对象?

我想知道的是,它可能是特定于驱动程序的,我如何知道何时应该调用 getWarnings() 并期望非 null 响应? 换句话说, JDBC 对象上是否存在警告,并且仅在该对象引发异常后才可以使用 getWarnings() 来获取警告? (这个异常就是警告?)

如果我的目标是观察每个警告,我是否应该在每次 JDBC 操作“只是为了确定”之后调用 getWarnings() 来查找警告?

In JDBC the Connection, Statement, and ResultSet types each have a getWarnings() method that is specified to produce the first warning associated with objects of that type. The second and subsequent warnings, if they exist, are chained onto the first warning (if it even exists, null is produced if there are no warnings).

The specs say that warnings associated with objects of these types are cleared after certain actions. For example warnings on a ResultSet are cleared when each new row is read.

The SQLWarning type is a subtype of SQLException. So would the presence of a warning be indicated by an exception? And that exception would be chained to the associated object if the exception's runtime type is SQLWarning?

What I'm wondering is this, and it might be driver specific, how do I know when I should call getWarnings() and expect a non-null response? Put another way, is a warning present on a JDBC object and available with getWarnings() only after that object has thrown an exception? (and that exception is the warning?)

Should I call getWarnings() to look for warnings after every JDBC operation "just to be sure" if my goal is to observe every warning?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

给妤﹃绝世温柔 2024-11-23 16:48:02

SQLWarning 对象是处理数据库访问警告的SQLException 的子类。

警告不会像异常那样停止应用程序的执行;它们只是提醒用户某些事情没有按计划发生。

可以在 Connection 对象、Statement 对象(包括 PreparedStatementCallableStatement 对象)或一个 ResultSet 对象。

这些类中的每一个都有一个 getWarnings 方法,您必须调用该方法才能查看调用对象上报告的第一个警告:

SQLWarning warning = stmt.getWarnings();
if (warning != null)
{
    System.out.println(\"n---Warning---n\");
    while (warning != null)
    {
        System.out.println(\"Message: \" + warning.getMessage());
        System.out.println(\"SQLState: \" + warning.getSQLState());
        System.out.print(\"Vendor error code: \");
        System.out.println(warning.getErrorCode());
        System.out.println(\"\");
        warning = warning.getNextWarning();
    }
}

SQLWarning objects are a subclass of SQLException that deal with database access warnings.

Warnings do not stop the execution of an application, as exceptions do; they simply alert the user that something did not happen as planned.

A warning can be reported on a Connection object, a Statement object (including PreparedStatement and CallableStatement objects), or a ResultSet object.

Each of these classes has a getWarnings method, which you must invoke in order to see the first warning reported on the calling object:

SQLWarning warning = stmt.getWarnings();
if (warning != null)
{
    System.out.println(\"n---Warning---n\");
    while (warning != null)
    {
        System.out.println(\"Message: \" + warning.getMessage());
        System.out.println(\"SQLState: \" + warning.getSQLState());
        System.out.print(\"Vendor error code: \");
        System.out.println(warning.getErrorCode());
        System.out.println(\"\");
        warning = warning.getNextWarning();
    }
}
牵强ㄟ 2024-11-23 16:48:02

是的,如果您确实想观察每个警告,则需要显式 getWarnings 。但你为什么要做这样的事呢?

或者,Spring 的 JdbcTemplate 为您提供了记录警告或在出现警告时抛出 SQLWarningException 的选项。默认行为是记录警告,因为它们是警告。希望这也足以满足您的目的。

Yes, you'd need to getWarnings explicitly if you really want to observe every warning. But why would you want to do such a thing?

Alternatively Spring's JdbcTemplate gives you the option of logging warnings or throwing SQLWarningException when there are warnings. The default behavior is to log warnings because, well, they're warnings. Hopefully this is sufficient for your purposes, too.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文