<div dir="ltr"><br><br><div class="gmail_quote">On Mon, Dec 7, 2009 at 9:07 PM, Henning Thielemann <span dir="ltr">&lt;<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
On Mon, 7 Dec 2009, Michael Snoyman wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The only opinion I&#39;ve stated so far is that it&#39;s ridiculous to constantly demand<br>
that people follow your definition of error vs exception, since the line is incredibly<br>
blurry and it buys you very little.<br>
</blockquote>
<br></div>
If you have an example that is not contained in my article on the Haskell Wiki, where you think the error vs. exception distinction is not appropriate, please let me know and will think about it.<div><div></div><div class="h5">
<br>
<br>
<a href="http://www.haskell.org/haskellwiki/Error_vs._Exception" target="_blank">http://www.haskell.org/haskellwiki/Error_vs._Exception</a><br>
</div></div></blockquote></div><br>I think it&#39;s a silly, unnecessary distinction. Sure, when you&#39;re teaching beginning programmers how to deal with out-of-bounds versus file not found, you can use the terminology. But as far as insisting that library authors have their programs die on an error, it&#39;s pointless. Having errors thrown as their own type of exception (like AssertionFailed, for example) is a much more resilient option, and for decent programmers who understand they shouldn&#39;t just catch every exception and return a default value, there is no downside. I don&#39;t care to make systems less resilient to deal with the sub-par programmer.<br>
<br>I turn it around: give me an example where it&#39;s better for the runtime to exit than for some type of exception to be thrown, and *I&#39;ll* think about it ;).<br><br>Michael<br></div>