对 spring 的 exception 处理方式真是不适应# Java - 爪哇娇娃
y*d
1 楼
把各种情况都转换成了 unchecked exception, 搞的常常不知道什么地方会蹦出来什么
样的臭虫; 我觉得最少在函数里面得声明一下有什么样的 unchecked exception 才好,
但是很多地方连这个也没有;
样的臭虫; 我觉得最少在函数里面得声明一下有什么样的 unchecked exception 才好,
但是很多地方连这个也没有;
t*e
2 楼
不适应不代表不好，事实上exception handling是spring里非常有价值的东西，每本
spring的书都会提到。那些jdbc的破checked exceptions，你catch了也没用，什么都
干不了，就应当转成runtime exception。
spring的书都会提到。那些jdbc的破checked exceptions，你catch了也没用，什么都
干不了，就应当转成runtime exception。
y*d
3 楼
I want to handle the situations when a sql/jms/other server is rebooting,
and also want to handle the 'interrupted' exception, for which case I want
the thread to make a decent exit.
with these unchecked exceptions, it seems to be rather hard to do this.
【在 t*******e 的大作中提到】
: 不适应不代表不好，事实上exception handling是spring里非常有价值的东西，每本
: spring的书都会提到。那些jdbc的破checked exceptions，你catch了也没用，什么都
: 干不了，就应当转成runtime exception。
and also want to handle the 'interrupted' exception, for which case I want
the thread to make a decent exit.
with these unchecked exceptions, it seems to be rather hard to do this.
【在 t*******e 的大作中提到】
: 不适应不代表不好，事实上exception handling是spring里非常有价值的东西，每本
: spring的书都会提到。那些jdbc的破checked exceptions，你catch了也没用，什么都
: 干不了，就应当转成runtime exception。
t*e
4 楼
Why can't you catch the unchecked exceptions? Almost each JDBC exception
type is mapped to a corresponding Spring runtime exception.
【在 y***d 的大作中提到】
: I want to handle the situations when a sql/jms/other server is rebooting,
: and also want to handle the 'interrupted' exception, for which case I want
: the thread to make a decent exit.
: with these unchecked exceptions, it seems to be rather hard to do this.
type is mapped to a corresponding Spring runtime exception.
【在 y***d 的大作中提到】
: I want to handle the situations when a sql/jms/other server is rebooting,
: and also want to handle the 'interrupted' exception, for which case I want
: the thread to make a decent exit.
: with these unchecked exceptions, it seems to be rather hard to do this.
y*d
5 楼
The jdbc/hibernate templates seem to be fine.
I went across some buggy spring components that failed to declare the
exceptions in the function signature, and gave me some surprises.
Now I think it is more of an immature implemtation problem.
【在 t*******e 的大作中提到】
: Why can't you catch the unchecked exceptions? Almost each JDBC exception
: type is mapped to a corresponding Spring runtime exception.
I went across some buggy spring components that failed to declare the
exceptions in the function signature, and gave me some surprises.
Now I think it is more of an immature implemtation problem.
【在 t*******e 的大作中提到】
: Why can't you catch the unchecked exceptions? Almost each JDBC exception
: type is mapped to a corresponding Spring runtime exception.
i*e
6 楼
Spring's use of unchecked data access exceptions is consistent with that of
many - probably most - successful persistence frameworks. (Indeed, it was
partly inspired by JDO.) JDBC is one of the few data access APIs to use
checked exceptions. TopLink and JDO, for example, use unchecked exceptions
exclusively. Hibernate switched from checked to unchecked exceptions in
version 3.
这是Rod讲解Spring JDBC的原话
http://www.theserverside.com/news/1364527/Introduction-to-the-S
大体意思是:
By wrapping JDBC check exceptions with runtime exception - i.e.
DataAccessException, Java IDE and compiler will not nag you about uncaught
checked exceptions.
persistence layer just need to worry about things it can recover.
try { // do spring dao work } catch (OptimisticLockingFailureException ex) {
// i can handle this }
and application layer just need to catch DAE and eat it, if it doesn't want
end-user to see the ugly stack trace.
try { // do spring work } catch (DataAccessException ex) {
// fatal; just eat it }
====
The Spring data access exception hierarchy is based on unchecked (runtime)
exceptions. Having worked with Spring on several projects I'm more and more
convinced that this was the right decision.
Data access exceptions not usually recoverable. For example, if we can't
connect to the database, a particular business object is unlikely to be able
to work around the problem. One potential exception is optimistic locking
violations, but not all applications use optimistic locking. It's usually
bad to be forced to write code to catch fatal exceptions that can't be
sensibly handled. Letting them propagate to top-level handlers like the
servlet or EJB container is usually more appropriate. All Spring data access
exceptions are subclasses of DataAccessException, so if we do choose to
catch all Spring data access exceptions, we can easily do so.
Note that if we do want to recover from an unchecked data access exception,
we can still do so. We can write code to handle only the recoverable
condition. For example, if we consider that only an optimistic locking
violation is recoverable, we can write code in a Spring DAO as follows:
try { // do work } catch (OptimisticLockingFailureException ex) { // I'm
interested in this }
If Spring data access exceptions were checked, we'd need to write the
following code. Note that we could choose to write this anyway:
try { // do work } catch (OptimisticLockingFailureException ex) { // I'm
interested in this } catch (DataAccessException ex) { // Fatal; just rethrow
it }
One potential objection to the first example - that the compiler can't
enforce handling the potentially recoverable exception - applies also to the
second. Because we're forced to catch the base exception (
DataAccessException), the compiler won't enforce a check for a subclass (
OptimisticLockingFailureException). So the compiler would force us to write
code to handle an unrecoverable problem, but provide no help in forcing us
to deal with the recoverable problem.
Spring's use of unchecked data access exceptions is consistent with that of
many - probably most - successful persistence frameworks. (Indeed, it was
partly inspired by JDO.) JDBC is one of the few data access APIs to use
checked exceptions. TopLink and JDO, for example, use unchecked exceptions
exclusively. Hibernate switched from checked to unchecked exceptions in
version 3.
Spring JDBC can help you in several ways:
You'll never need to write a finally block again to use JDBC
Connection leaks will be a thing of the past
You'll need to write less code overall, and that code will be clearly
focused on the necessary SQL
You'll never need to dig through your RDBMS documentation to work out
what obscure error code it returns for a bad column name. Your application
won't be dependent on RDBMS-specific error handling code.
Whatever persistence technology use, you'll find it easy to implement
the DAO pattern without business logic depending on any particular data
access API.
You'll benefit from improved portability (compared to raw JDBC) in
advanced areas such as BLOB handling and invoking stored procedures that
return result sets.
In practice we find that all this amounts to substantial productivity gains
and fewer bugs. I used to loathe writing JDBC code; now I find that I can
focus on the SQL I want to execute, rather than the incidentals of JDBC
resource management.
many - probably most - successful persistence frameworks. (Indeed, it was
partly inspired by JDO.) JDBC is one of the few data access APIs to use
checked exceptions. TopLink and JDO, for example, use unchecked exceptions
exclusively. Hibernate switched from checked to unchecked exceptions in
version 3.
这是Rod讲解Spring JDBC的原话
http://www.theserverside.com/news/1364527/Introduction-to-the-S
大体意思是:
By wrapping JDBC check exceptions with runtime exception - i.e.
DataAccessException, Java IDE and compiler will not nag you about uncaught
checked exceptions.
persistence layer just need to worry about things it can recover.
try { // do spring dao work } catch (OptimisticLockingFailureException ex) {
// i can handle this }
and application layer just need to catch DAE and eat it, if it doesn't want
end-user to see the ugly stack trace.
try { // do spring work } catch (DataAccessException ex) {
// fatal; just eat it }
====
The Spring data access exception hierarchy is based on unchecked (runtime)
exceptions. Having worked with Spring on several projects I'm more and more
convinced that this was the right decision.
Data access exceptions not usually recoverable. For example, if we can't
connect to the database, a particular business object is unlikely to be able
to work around the problem. One potential exception is optimistic locking
violations, but not all applications use optimistic locking. It's usually
bad to be forced to write code to catch fatal exceptions that can't be
sensibly handled. Letting them propagate to top-level handlers like the
servlet or EJB container is usually more appropriate. All Spring data access
exceptions are subclasses of DataAccessException, so if we do choose to
catch all Spring data access exceptions, we can easily do so.
Note that if we do want to recover from an unchecked data access exception,
we can still do so. We can write code to handle only the recoverable
condition. For example, if we consider that only an optimistic locking
violation is recoverable, we can write code in a Spring DAO as follows:
try { // do work } catch (OptimisticLockingFailureException ex) { // I'm
interested in this }
If Spring data access exceptions were checked, we'd need to write the
following code. Note that we could choose to write this anyway:
try { // do work } catch (OptimisticLockingFailureException ex) { // I'm
interested in this } catch (DataAccessException ex) { // Fatal; just rethrow
it }
One potential objection to the first example - that the compiler can't
enforce handling the potentially recoverable exception - applies also to the
second. Because we're forced to catch the base exception (
DataAccessException), the compiler won't enforce a check for a subclass (
OptimisticLockingFailureException). So the compiler would force us to write
code to handle an unrecoverable problem, but provide no help in forcing us
to deal with the recoverable problem.
Spring's use of unchecked data access exceptions is consistent with that of
many - probably most - successful persistence frameworks. (Indeed, it was
partly inspired by JDO.) JDBC is one of the few data access APIs to use
checked exceptions. TopLink and JDO, for example, use unchecked exceptions
exclusively. Hibernate switched from checked to unchecked exceptions in
version 3.
Spring JDBC can help you in several ways:
You'll never need to write a finally block again to use JDBC
Connection leaks will be a thing of the past
You'll need to write less code overall, and that code will be clearly
focused on the necessary SQL
You'll never need to dig through your RDBMS documentation to work out
what obscure error code it returns for a bad column name. Your application
won't be dependent on RDBMS-specific error handling code.
Whatever persistence technology use, you'll find it easy to implement
the DAO pattern without business logic depending on any particular data
access API.
You'll benefit from improved portability (compared to raw JDBC) in
advanced areas such as BLOB handling and invoking stored procedures that
return result sets.
In practice we find that all this amounts to substantial productivity gains
and fewer bugs. I used to loathe writing JDBC code; now I find that I can
focus on the SQL I want to execute, rather than the incidentals of JDBC
resource management.
i*e
7 楼
另外这是有关unchecked/checked exception的讨论
http://www.javapractices.com/topic/TopicAction.do?Id=129
unchecked ex = unrecoverable, for example NPE, IAE
checked ex = recoverable, representing invalid conditions in areas outside
the immediate control of the program (invalid user input, database problems,
network outages, absent files)
(here, database problem is considered as outside of main program logic)
所以Sun的人认为JDBC是side logic, JDBC layer出问题了, main Java program是
recoverable的, 所以就把JDBC搞成checked exception.
搞Data Persistance的人当然认为Data Access Exception is non-recoverable, 所以
就搞成unchecked exception.
另外RuntimeException是Exception的subclass, 可以catch,可以rethrow, 也可以
specify在method上(注意exception不是signature的一部分,只是告诉compiler一下),
只是这样对常人来说就比较confusing, 会说你Y到底让我catch还是不catch? 不过
Spring JDBC/TopLink/JDO/H8倒是应该specify all their unchecked exceptions, 这
样楼主就没有什么"不适应"的了, 想catch的时候一把都给catch了
http://www.javapractices.com/topic/TopicAction.do?Id=129
unchecked ex = unrecoverable, for example NPE, IAE
checked ex = recoverable, representing invalid conditions in areas outside
the immediate control of the program (invalid user input, database problems,
network outages, absent files)
(here, database problem is considered as outside of main program logic)
所以Sun的人认为JDBC是side logic, JDBC layer出问题了, main Java program是
recoverable的, 所以就把JDBC搞成checked exception.
搞Data Persistance的人当然认为Data Access Exception is non-recoverable, 所以
就搞成unchecked exception.
另外RuntimeException是Exception的subclass, 可以catch,可以rethrow, 也可以
specify在method上(注意exception不是signature的一部分,只是告诉compiler一下),
只是这样对常人来说就比较confusing, 会说你Y到底让我catch还是不catch? 不过
Spring JDBC/TopLink/JDO/H8倒是应该specify all their unchecked exceptions, 这
样楼主就没有什么"不适应"的了, 想catch的时候一把都给catch了
t*e
8 楼
Very useful information. There are merely 2 exceptions developers should
catch in programming Spring-based persistence,
OptimisticLockingFailureException & PessimisticLockingFailureException(
DeadlockLoserDataAccessException).
problems,
【在 i****e 的大作中提到】
: 另外这是有关unchecked/checked exception的讨论
: http://www.javapractices.com/topic/TopicAction.do?Id=129
: unchecked ex = unrecoverable, for example NPE, IAE
: checked ex = recoverable, representing invalid conditions in areas outside
: the immediate control of the program (invalid user input, database problems,
: network outages, absent files)
: (here, database problem is considered as outside of main program logic)
: 所以Sun的人认为JDBC是side logic, JDBC layer出问题了, main Java program是
: recoverable的, 所以就把JDBC搞成checked exception.
: 搞Data Persistance的人当然认为Data Access Exception is non-recoverable, 所以
catch in programming Spring-based persistence,
OptimisticLockingFailureException & PessimisticLockingFailureException(
DeadlockLoserDataAccessException).
problems,
【在 i****e 的大作中提到】
: 另外这是有关unchecked/checked exception的讨论
: http://www.javapractices.com/topic/TopicAction.do?Id=129
: unchecked ex = unrecoverable, for example NPE, IAE
: checked ex = recoverable, representing invalid conditions in areas outside
: the immediate control of the program (invalid user input, database problems,
: network outages, absent files)
: (here, database problem is considered as outside of main program logic)
: 所以Sun的人认为JDBC是side logic, JDBC layer出问题了, main Java program是
: recoverable的, 所以就把JDBC搞成checked exception.
: 搞Data Persistance的人当然认为Data Access Exception is non-recoverable, 所以
i*e
9 楼
RuntimeException是Exception的subclass, 可以catch,可以rethrow, 也可以
specify/declare在method的delaration上(注意楼主在这里有点概念不清, throws
exception不是signature的一部分, 只是告诉compiler如果是checked exception,
compile时候帮忙check一下; 还有就是subclass的overiding method只能throws同样或
inherited checked exceptions).
Spring JDBC/TopLink/JDO/H8既然跟JDBC反着干, 理应specify all their unchecked
exceptions on method declaration, 其实Spring JDBCTemplate也是这样做了.
http://static.springsource.org/spring/docs/2.0.x/api/org/spring
而且由于是throws RuntimeException, 不catch, compiler也不会报错.
正如楼主说得, Spring有一些3rd-class packages, 大干快上, 用来应付
consulting project的, 细节不够也难免
specify/declare在method的delaration上(注意楼主在这里有点概念不清, throws
exception不是signature的一部分, 只是告诉compiler如果是checked exception,
compile时候帮忙check一下; 还有就是subclass的overiding method只能throws同样或
inherited checked exceptions).
Spring JDBC/TopLink/JDO/H8既然跟JDBC反着干, 理应specify all their unchecked
exceptions on method declaration, 其实Spring JDBCTemplate也是这样做了.
http://static.springsource.org/spring/docs/2.0.x/api/org/spring
而且由于是throws RuntimeException, 不catch, compiler也不会报错.
正如楼主说得, Spring有一些3rd-class packages, 大干快上, 用来应付
consulting project的, 细节不够也难免
相关阅读
菜鸟问题GC finalize()一问怎么连接Cloudscape数据库?Generating Java code in SCR谁用过 BlueJ ? 有什么好和不好的地方使用Clob的setString方法出现如下错误swing questionAuthenticated Applet Doesn't Show in VBAppant junit and log4j can't work togethersimple swing question要不要搞个.net版?不能用last()之类的JDBC函数Anyone used JESS?any tools for ...Weblogic的CVS问题Help!! a cookie questionWho can help for DFS search program?怎么这么萧条捏怎么从键盘输入整数或float?Swing help