<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Exceptions Without Root Cause</title>
	<atom:link href="http://www.subbu.org/blog/2005/11/exceptions-without-root-cause/feed" rel="self" type="application/rss+xml" />
	<link>http://www.subbu.org/blog/2005/11/exceptions-without-root-cause</link>
	<description></description>
	<lastBuildDate>Wed, 08 Feb 2012 05:16:45 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Chuck</title>
		<link>http://www.subbu.org/blog/2005/11/exceptions-without-root-cause/comment-page-1#comment-79</link>
		<dc:creator>Chuck</dc:creator>
		<pubDate>Thu, 07 Feb 2008 17:43:03 +0000</pubDate>
		<guid isPermaLink="false">http://wp.subbu.org/2005/11/exceptions-without-root-cause/#comment-79</guid>
		<description>Hi Subbu,

Thanks for this helpful posting.

Regarding your example of the &quot;right&quot; way to throw a ServletException, wouldn&#039;t it be better to also include the root cause in the constructor, like so?

&lt;pre&gt;
try {
// Do something
} catch(SomeException e) {
ServletException se = new ServletException(e.getMessage(), e);
se.initCause(e);
throw se;
}
&lt;/pre&gt;

This way, &quot;legacy&quot; code calling ServletException.getRootCause() will still work too.

Also, regarding later versions of ServletException (and other similar such exception classes), they should simply override the getCause() method like so, to take advantage of exception chaining without breaking old code:

&lt;pre&gt;
public Throwable getCause() {
return (super.getCause() == null) ? this.rootCause : super.getCause();
}
&lt;/pre&gt;

In fact, the comment for Throwable.getCause() includes the following wording:

&#039;While it is typically unnecessary to override this method, a subclass can override it to return a cause set by some other means.  This is appropriate for a &quot;legacy chained throwable&quot; that predates the addition of chained exceptions to Throwable.&#039;

Why don&#039;t the later versions of these exception types actually do this?
</description>
		<content:encoded><![CDATA[<p>Hi Subbu,</p>
<p>Thanks for this helpful posting.</p>
<p>Regarding your example of the &#8220;right&#8221; way to throw a ServletException, wouldn&#8217;t it be better to also include the root cause in the constructor, like so?</p>
<pre>
try {
// Do something
} catch(SomeException e) {
ServletException se = new ServletException(e.getMessage(), e);
se.initCause(e);
throw se;
}
</pre>
<p>This way, &#8220;legacy&#8221; code calling ServletException.getRootCause() will still work too.</p>
<p>Also, regarding later versions of ServletException (and other similar such exception classes), they should simply override the getCause() method like so, to take advantage of exception chaining without breaking old code:</p>
<pre>
public Throwable getCause() {
return (super.getCause() == null) ? this.rootCause : super.getCause();
}
</pre>
<p>In fact, the comment for Throwable.getCause() includes the following wording:</p>
<p>&#8216;While it is typically unnecessary to override this method, a subclass can override it to return a cause set by some other means.  This is appropriate for a &#8220;legacy chained throwable&#8221; that predates the addition of chained exceptions to Throwable.&#8217;</p>
<p>Why don&#8217;t the later versions of these exception types actually do this?</p>
]]></content:encoded>
	</item>
</channel>
</rss>

