关于[异常]的实际问题

看了[深度话题]版大家的讨论，因为帖子太多，看得有点头晕，有一种观点是像SQLException这种不可恢复的异常应该log下来，并转化为未检查异常再抛出，而使用已检查异常应该是在正常的事务流中，比如UserNotFoundException。
我也比较赞同这种方法，但我比较疑惑的地方是前一种：抛出RuntimeException之后，调用代码（不知道和大家说的客户是不是指它）还是应该catch它的以便在浏览器上返回错误，否则浏览网页的人会因为出现了不可恢复的异常而不能继续使用服务，但却得不到网页出错的信息。既然是这样，用已检查异常不也是一样的吗？:(

你可以把异常一直抛到最外面，然后用一个拦截器统一处理，比如转到同一个出错页面，在这里根据异常类型或者错误码输出对应的提示信息。比如抓到DAOException就输出“数据库访问出错”，再把错误代码写出来，用户就可以拿这个错误代码来咨询管理员了。

举个客户代码的例子。比如说，我们有getUserByLoginName这么一个方法，如果数据库出错、配置文件不正确、没有这个登录名的用户……总而言之，取不到这么一个User对象，它就会抛出一个异常——当然，是RuntimeException的子类。那么它的客户代码要怎么去使用它呢？如果是在登录界面上，我们就把异常全部抓住，不管你是什么原因取不到用户对象，总之我让登录动作失败就行了。如果是在修改用户资料的页面上，就不能这么做，我就得提示一个出错信息给用户，或者干脆扔他到统一的出错页面去。

这里的关键是：getUserByLoginName这个方法的实现者无法去预料他的使用者要怎么处理这里出去的错误——他要简单地忽略这个错误吗？或者有错误就不能再接着做任何事？所以他不应该在接口上给使用者预设那么多的限制。而另一方面，这个方法的设计者也无法预料会有哪些问题出现——除了数据库之外，也许LDAP或者JMS也能导致获得用户信息出错呢。要是用checked exception清楚地描述了这里可能出来的异常，以后实现方式发生改变就很可能破坏接口。所以，我一贯的做法是抛出runtime exception，使用者自己看着办，有办法处理就处理，没办法处理就一直往外抛好了。

是说转换成RuntimeException的子类吧？那么一般对异常的处理是不是log先，然后能处理就处理，不能处理就抛呢？未检查异常需要不需要嵌套呢？
有的时候设计上的问题使Hibernate抛了异常，我仔细看了看，root cause里面还有root cause，看来是嵌套了好几层的异常，这样有什么好处呢？
还有，真正能找到问题的却是在顶层，照例说应该是在最底层的root才对啊......