我试图在侦听器的contextinitialized方法中执行sql语句，但当我运行gretty local server时，它抛出runtimeexception错误。我不明白，为什么。当我把它注解掉时，它没有遇到任何错误 ps.executeQuery(); .
@Override
public void contextInitialized(ServletContextEvent sce){
ServletContext sc = sce.getServletContext();
DataSource pool = new ConnectionPoolFactory().createConnectionPool();
String sql = "create table test (id int);";
try (Connection conn = pool.getConnection();
PreparedStatement ps = conn.prepareStatement(sql)) {
ps.executeQuery();
} catch (SQLException e) {
throw new RuntimeException();
}
}
1条答案
按热度按时间oyt4ldly1#
“医生，我按这儿的时候疼！”
好吧，那就别这样了。
这是：
一句话就是疯了。你犯了一个有用的错误，其中包括5个方便的方面，可以帮助你找出哪里出了问题：
异常的实际类型（可以是sqlexception的子类；'databasenotavailableexception'（例如）
与之关联的消息
堆栈跟踪，它精确地指向导致它的代码行
原因例外可以有原因，原因本身就是例外（好吧，抛出的）。原因往往比异常本身更有用。
一连串的例外。这很少有用。
您已经决定将它们全部放入垃圾中，用一个runtimeexception来替换它，这个runtimeexception不提供任何类型的有用信息。
不要那样做。
正确的异常处理需要减少对异常的恐惧
throws方法条款。有一个方法可以做数据库的东西，并且这个方法的设计清楚地表明可以这样做（如果这个方法名为'query'或者包含任何明显表示sql的单词，答案是清楚的：是的，它可以），那么这个方法应该声明为throws SQLException，例如。第二，在少数情况下，向前抛出异常不起作用，如果捕获到异常，则不希望只记录它并继续，也不希望在不首先设置原因的情况下抛出其他异常。这是标准的“我不知道该做什么，我不想再花时间考虑它”异常处理程序：
那个
, e至关重要的是，它将实际异常设置为原因，以便您在堆栈跟踪和日志中实际看到它。很常见的情况是，对e.printStackTrace(). 不要这样做-90%的java示例都不好。这会导致各种各样的问题，因为“日志”转到standarderr（这比让它们转到您正在操作的上下文的异常处理程序要灵活得多）。例如，如果编写web处理程序，e.printStackTrace()只是把垃圾堆倒出来。向上抛出异常将转储堆栈，并允许框架添加有关触发问题的请求的信息，并提供适当的htto status 500错误页。另外，只要运行printstacktrace，代码就会继续执行，这显然不是您想要的：出了什么问题-盲目地继续执行会保证您的软件默默地做错误的事情，或者导致进一步的异常，从而导致一个错误，导致数百个堆栈跟踪淹没您的syserr。一旦您在这里和代码中的其他地方解决了这个问题，实际的问题很可能会一目了然。有关sql server关闭或sql中出现语法错误的信息。