<?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/"
	xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments for Wakaaaao !</title>
	<atom:link href="http://wakao.wordpress.com/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://wakao.wordpress.com</link>
	<description>View from an elated state of mind</description>
	<lastBuildDate>Thu, 05 Feb 2009 16:17:32 +0000</lastBuildDate>
	<generator>http://wordpress.com/</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Comment on See how fast you can type! by anonymous</title>
		<link>http://wakao.wordpress.com/2006/07/13/see-how-fast-you-can-type/#comment-2809</link>
		<dc:creator>anonymous</dc:creator>
		<pubDate>Thu, 05 Feb 2009 16:17:32 +0000</pubDate>
		<guid isPermaLink="false">http://wakao.wordpress.com/2006/07/13/see-how-fast-you-can-type/#comment-2809</guid>
		<description>Damn I got ~59wpm and now I&#039;m sad...</description>
		<content:encoded><![CDATA[<p>Damn I got ~59wpm and now I&#8217;m sad&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on w.bloggar with wordpress.com by shaunakpandit</title>
		<link>http://wakao.wordpress.com/2005/11/24/wbloggar-with-wordpresscom/#comment-2808</link>
		<dc:creator>shaunakpandit</dc:creator>
		<pubDate>Sat, 06 Sep 2008 18:45:25 +0000</pubDate>
		<guid isPermaLink="false">https://wakao.wordpress.com/2005/11/24/wbloggar-with-wordpresscom/#comment-2808</guid>
		<description>gr8 thanks</description>
		<content:encoded><![CDATA[<p>gr8 thanks</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on See how fast you can type! by Caitlyn</title>
		<link>http://wakao.wordpress.com/2006/07/13/see-how-fast-you-can-type/#comment-2807</link>
		<dc:creator>Caitlyn</dc:creator>
		<pubDate>Mon, 23 Jun 2008 19:44:52 +0000</pubDate>
		<guid isPermaLink="false">http://wakao.wordpress.com/2006/07/13/see-how-fast-you-can-type/#comment-2807</guid>
		<description>Hello my name is Caitlyn Thrush and I am from Michigab</description>
		<content:encoded><![CDATA[<p>Hello my name is Caitlyn Thrush and I am from Michigab</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Implement &#8220;Search results&#8221; using Hibernate by celpjefscycle</title>
		<link>http://wakao.wordpress.com/2006/09/29/implement-search-results-using-hibernate/#comment-2799</link>
		<dc:creator>celpjefscycle</dc:creator>
		<pubDate>Sat, 12 Jan 2008 09:13:44 +0000</pubDate>
		<guid isPermaLink="false">http://wakao.wordpress.com/2006/09/29/implement-search-results-using-hibernate/#comment-2799</guid>
		<description>Thanks for information. 
many interesting things 
Celpjefscylc</description>
		<content:encoded><![CDATA[<p>Thanks for information.<br />
many interesting things<br />
Celpjefscylc</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Must never do Antipatterns &#8211; Exception Handling by Web 2.0 Announcer</title>
		<link>http://wakao.wordpress.com/2006/09/28/must-never-do-antipatterns-exception-handling/#comment-1992</link>
		<dc:creator>Web 2.0 Announcer</dc:creator>
		<pubDate>Sun, 10 Jun 2007 14:45:58 +0000</pubDate>
		<guid isPermaLink="false">http://wakao.wordpress.com/2006/09/28/must-never-do-antipatterns-exception-handling/#comment-1992</guid>
		<description>&lt;strong&gt;Must never do Antipatterns - Exception Handling&lt;/strong&gt;

[...]This is one of the most annoying error-handling antipatterns. Either log the exception, or throw it, but never do both.[...]</description>
		<content:encoded><![CDATA[<p><strong>Must never do Antipatterns &#8211; Exception Handling</strong></p>
<p>[...]This is one of the most annoying error-handling antipatterns. Either log the exception, or throw it, but never do both.[...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Must never do Antipatterns &#8211; Exception Handling by anjan bacchu</title>
		<link>http://wakao.wordpress.com/2006/09/28/must-never-do-antipatterns-exception-handling/#comment-241</link>
		<dc:creator>anjan bacchu</dc:creator>
		<pubDate>Wed, 18 Oct 2006 07:25:10 +0000</pubDate>
		<guid isPermaLink="false">http://wakao.wordpress.com/2006/09/28/must-never-do-antipatterns-exception-handling/#comment-241</guid>
		<description>hi there,

  In case you want to chain exception and then only print/log exceptions at the higher layer,   I noticed that if you use the XML Formatter(in java), the cause exception (the source of the exception) is not printed. Only if you use the Simple Formatter, the cause exception stack trace is printed.

don&#039;t know why, though?

BR,
~A</description>
		<content:encoded><![CDATA[<p>hi there,</p>
<p>  In case you want to chain exception and then only print/log exceptions at the higher layer,   I noticed that if you use the XML Formatter(in java), the cause exception (the source of the exception) is not printed. Only if you use the Simple Formatter, the cause exception stack trace is printed.</p>
<p>don&#8217;t know why, though?</p>
<p>BR,<br />
~A</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Must never do Antipatterns &#8211; Exception Handling by mv</title>
		<link>http://wakao.wordpress.com/2006/09/28/must-never-do-antipatterns-exception-handling/#comment-162</link>
		<dc:creator>mv</dc:creator>
		<pubDate>Sat, 30 Sep 2006 00:55:03 +0000</pubDate>
		<guid isPermaLink="false">http://wakao.wordpress.com/2006/09/28/must-never-do-antipatterns-exception-handling/#comment-162</guid>
		<description>The original post characterizing &#039;log and throw&#039; as an antipattern is mostly correct in the large: the fundamental problem with the exception syntax in languages like java and c# is the pathological use of the exception construct for domain logic handling.  Thus the &#039;log and throw&#039; approach doesn&#039;t address the underlying issue, which is poor design.

Alas, many common api&#039;s and vendor api&#039;s now use the exception syntax where better decompostion and error reporting would be cleaner, more maintainable, more portable, more extensible, and just plain more correct.  So what&#039;s a poor developer to do?

Wrap the pathological exceptions. Design layered services which appropriately abstract implementation details at each level and report results (including &#039;error&#039; cases) in the semantics of the usage domain, not the implementation details.  Thus the reply about needing the trace detail is a bit off base.  One can always log stuff anyway, if needed.  

As a programming technique, Ricky Clarkson&#039;s approach: using a callback is one of the better approaches that I&#039;ve seen.  Kudos.

But the fundamental issue is still design, design, design.</description>
		<content:encoded><![CDATA[<p>The original post characterizing &#8216;log and throw&#8217; as an antipattern is mostly correct in the large: the fundamental problem with the exception syntax in languages like java and c# is the pathological use of the exception construct for domain logic handling.  Thus the &#8216;log and throw&#8217; approach doesn&#8217;t address the underlying issue, which is poor design.</p>
<p>Alas, many common api&#8217;s and vendor api&#8217;s now use the exception syntax where better decompostion and error reporting would be cleaner, more maintainable, more portable, more extensible, and just plain more correct.  So what&#8217;s a poor developer to do?</p>
<p>Wrap the pathological exceptions. Design layered services which appropriately abstract implementation details at each level and report results (including &#8216;error&#8217; cases) in the semantics of the usage domain, not the implementation details.  Thus the reply about needing the trace detail is a bit off base.  One can always log stuff anyway, if needed.  </p>
<p>As a programming technique, Ricky Clarkson&#8217;s approach: using a callback is one of the better approaches that I&#8217;ve seen.  Kudos.</p>
<p>But the fundamental issue is still design, design, design.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Must never do Antipatterns &#8211; Exception Handling by Ricky Clarkson</title>
		<link>http://wakao.wordpress.com/2006/09/28/must-never-do-antipatterns-exception-handling/#comment-161</link>
		<dc:creator>Ricky Clarkson</dc:creator>
		<pubDate>Fri, 29 Sep 2006 18:42:34 +0000</pubDate>
		<guid isPermaLink="false">http://wakao.wordpress.com/2006/09/28/must-never-do-antipatterns-exception-handling/#comment-161</guid>
		<description>I&#039;d rather use a callback to handle exceptions.

Instead of

&lt;code&gt;
void method() throws IOException
{
    new FileStuff().write();
}
&lt;/code&gt;
I&#039;d have:
&lt;code&gt;
void method(SideEffect ioExceptionHandler)
{
    try
    {
        new FileStuff().write();
    }
    catch (IOException exception)
    {
        ioExceptionHandler.run(exception);
    }
}

interface SideEffect[T]
{
    void run(T input);
}
&lt;/code&gt;

Then they can be chained fairly easily, and you don&#039;t feel the need to deal with exceptions before you need to.  It also gets away from the ugly try..catch in client code - generally a client will satisfy a method parameter requirement better than they will handle an exception.</description>
		<content:encoded><![CDATA[<p>I&#8217;d rather use a callback to handle exceptions.</p>
<p>Instead of</p>
<p><code><br />
void method() throws IOException<br />
{<br />
    new FileStuff().write();<br />
}<br />
</code><br />
I&#8217;d have:<br />
<code><br />
void method(SideEffect ioExceptionHandler)<br />
{<br />
    try<br />
    {<br />
        new FileStuff().write();<br />
    }<br />
    catch (IOException exception)<br />
    {<br />
        ioExceptionHandler.run(exception);<br />
    }<br />
}</p>
<p>interface SideEffect[T]<br />
{<br />
    void run(T input);<br />
}<br />
</code></p>
<p>Then they can be chained fairly easily, and you don&#8217;t feel the need to deal with exceptions before you need to.  It also gets away from the ugly try..catch in client code &#8211; generally a client will satisfy a method parameter requirement better than they will handle an exception.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Must never do Antipatterns &#8211; Exception Handling by Gene</title>
		<link>http://wakao.wordpress.com/2006/09/28/must-never-do-antipatterns-exception-handling/#comment-160</link>
		<dc:creator>Gene</dc:creator>
		<pubDate>Fri, 29 Sep 2006 17:39:23 +0000</pubDate>
		<guid isPermaLink="false">http://wakao.wordpress.com/2006/09/28/must-never-do-antipatterns-exception-handling/#comment-160</guid>
		<description>I don&#039;t think the author understands Java exceptions or logging well. Or perhaps he was overgeneralizing for effect.

Throwing an exception does not necessarily cause output.
Printing a stack trace does not necessarily write to the log.
Sometimes an exception must be thrown even though it will be gracefully dealt with higher in the stack, but you still want to log that it happened (and where it happened).</description>
		<content:encoded><![CDATA[<p>I don&#8217;t think the author understands Java exceptions or logging well. Or perhaps he was overgeneralizing for effect.</p>
<p>Throwing an exception does not necessarily cause output.<br />
Printing a stack trace does not necessarily write to the log.<br />
Sometimes an exception must be thrown even though it will be gracefully dealt with higher in the stack, but you still want to log that it happened (and where it happened).</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Must never do Antipatterns &#8211; Exception Handling by Jason Holbrook</title>
		<link>http://wakao.wordpress.com/2006/09/28/must-never-do-antipatterns-exception-handling/#comment-159</link>
		<dc:creator>Jason Holbrook</dc:creator>
		<pubDate>Fri, 29 Sep 2006 15:22:05 +0000</pubDate>
		<guid isPermaLink="false">http://wakao.wordpress.com/2006/09/28/must-never-do-antipatterns-exception-handling/#comment-159</guid>
		<description>When you are throwing exceptions back through a service call you can&#039;t get the detail on the caller side of what happened underneath. You have to log and throw.</description>
		<content:encoded><![CDATA[<p>When you are throwing exceptions back through a service call you can&#8217;t get the detail on the caller side of what happened underneath. You have to log and throw.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
