<?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: On Error handling</title>
	<atom:link href="http://mikie.iki.fi/wordpress/?feed=rss2&#038;p=5" rel="self" type="application/rss+xml" />
	<link>http://mikie.iki.fi/wordpress/?p=5</link>
	<description>Symbian, CS research and angst</description>
	<lastBuildDate>Mon, 15 Feb 2010 00:23:54 -0800</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Mika</title>
		<link>http://mikie.iki.fi/wordpress/?p=5&#038;cpage=1#comment-7</link>
		<dc:creator>Mika</dc:creator>
		<pubDate>Tue, 20 Dec 2005 13:53:53 +0000</pubDate>
		<guid isPermaLink="false">http://db.cs.helsinki.fi/~mraento/wordpress/?p=5#comment-7</guid>
		<description>Hmm. I rewrote some of that. The idea is that when you are considering what ImmediateCaller might do, you want to document all the interesting error conditions. To make that documentation as specific as possible, you may consider using checked exceptions, as they make the compiler verify your documentation. 

Now the fault is that there are not that many interesting &lt;em&gt;specific&lt;/em&gt; error conditions in well-designed APIs (e.g., you should not catch a file-not-found error when opening a file to create the file, you should use a OpenIfExistsOtherwiseCreate call instead, O_CREAT in unix-speak.). There are many things that may go wrong which merit their own error codes, descriptions or exception classes but even ImmediateCaller is not interested in most of them. 

Once ImmediateCaller is out of the picture, the need for specific exceptions goes away, as UpperLayer won&#039;t be able to do anything reasonable with that specific info. Most of the time the operation just fails or succeeds, and you either roll back or continue. So the necessity to either specify all those low-level errors in your exception specification, or having to map them to something else becomes just an unnecessary burden with no benefits. Especially since mapping them risks losing information.</description>
		<content:encoded><![CDATA[<p>Hmm. I rewrote some of that. The idea is that when you are considering what ImmediateCaller might do, you want to document all the interesting error conditions. To make that documentation as specific as possible, you may consider using checked exceptions, as they make the compiler verify your documentation. </p>
<p>Now the fault is that there are not that many interesting <em>specific</em> error conditions in well-designed APIs (e.g., you should not catch a file-not-found error when opening a file to create the file, you should use a OpenIfExistsOtherwiseCreate call instead, O_CREAT in unix-speak.). There are many things that may go wrong which merit their own error codes, descriptions or exception classes but even ImmediateCaller is not interested in most of them. </p>
<p>Once ImmediateCaller is out of the picture, the need for specific exceptions goes away, as UpperLayer won&#8217;t be able to do anything reasonable with that specific info. Most of the time the operation just fails or succeeds, and you either roll back or continue. So the necessity to either specify all those low-level errors in your exception specification, or having to map them to something else becomes just an unnecessary burden with no benefits. Especially since mapping them risks losing information.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: simo</title>
		<link>http://mikie.iki.fi/wordpress/?p=5&#038;cpage=1#comment-6</link>
		<dc:creator>simo</dc:creator>
		<pubDate>Tue, 20 Dec 2005 13:29:52 +0000</pubDate>
		<guid isPermaLink="false">http://db.cs.helsinki.fi/~mraento/wordpress/?p=5#comment-6</guid>
		<description>This sentence didn&#039;t really parse, could you please explain more: &quot;The discussion of the relative merits of checked exceptions can be seen as mixing cases ImmediateCaller and UpperLayer. &quot;</description>
		<content:encoded><![CDATA[<p>This sentence didn&#8217;t really parse, could you please explain more: &#8220;The discussion of the relative merits of checked exceptions can be seen as mixing cases ImmediateCaller and UpperLayer. &#8220;</p>
]]></content:encoded>
	</item>
</channel>
</rss>
