<div dir="ltr"><br><br><div class="gmail_quote">On Mon, Dec 7, 2009 at 5:30 AM, Ben Franksen <span dir="ltr">&lt;<a href="mailto:ben.franksen@online.de">ben.franksen@online.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><div></div><div class="h5">Michael Snoyman wrote:<br>
&gt; On Sun, Dec 6, 2009 at 12:55 AM, Henning Thielemann &lt;<br>
&gt; <a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>&gt; wrote:<br>
&gt;&gt; On Sun, 6 Dec 2009, Michael Snoyman wrote:<br>
&gt;&gt;  I think there are plenty of examples like web servers. A text editor<br>
&gt;&gt;  with<br>
&gt;&gt;&gt; plugins? I<br>
&gt;&gt;&gt; don&#39;t want to lose three hours worth of work just because some plugin<br>
&gt;&gt;&gt; wasn&#39;t written<br>
&gt;&gt;&gt; correctly. For many classes of programs, the distinction between error<br>
&gt;&gt;&gt; and exception is<br>
&gt;&gt;&gt; not only blurred, it&#39;s fully irrelevant. Harping on people every time<br>
&gt;&gt;&gt; they use error in<br>
&gt;&gt;&gt; the &quot;wrong&quot; sense seems unhelpful.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Hope my commenting on this subject doesn&#39;t become my own form of<br>
&gt;&gt;&gt; *pedantry*.<br>
&gt;&gt;&gt;<br>
&gt;&gt; In an earlier thread I have explained that one can consider a software<br>
&gt;&gt; architecture as divided into levels. What is an error in one level (text<br>
&gt;&gt; editor plugin, web server thread, operating system process) is an<br>
&gt;&gt; exception in the next higher level (text editor, web server, shell<br>
&gt;&gt; respectively). This doesn&#39;t reduce the importance to distinguish between<br>
&gt;&gt; errors and exceptions within one level. All approaches so far that I have<br>
&gt;&gt; seen in Haskell just mix exceptions and errors in an arbitrary way.<br>
&gt;&gt;<br>
&gt; I think we can all appreciate why it would be a bad thing is we treat<br>
&gt; exceptions as errors. For example, I don&#39;t want my program to crash on a<br>
&gt; file not found.<br>
&gt;<br>
&gt; On the other hand, what&#39;s so bad about treating errors as exceptions? If<br>
&gt; instead of the program crashing on an array-out-of-bound or pattern-match<br>
&gt; it throws an exception which can be caught, so what?<br>
<br>
</div></div>The error gets hidden instead of fixed?<br>
<br>
Cheers<br>
<font color="#888888">Ben<br>
</font><div><div></div><div class="h5"><br></div></div></blockquote><div>You&#39;re right; bad programmers could do this. A good programmer will know to do one of two things when it gets an exception it does not know how to handle:<br>
<br>* Die with an error message.<br>* In cases like web servers, print an informative error message (eg, hopefully more useful than &quot;Prelude: head&quot;) and continue doing something else.<br><br>I think the kind of programmers who just ignore exceptions and try to keep going are what I think of as over-defensive programmers, who in a misguided attempt to make their code more robust think that they should eliminate any possibility of not returning a result. I saw my share of this kind of code at my previous job, and when you&#39;re dealing with data processing programs, it&#39;s *very* irritating when suddenly you have garbage data because someone thought &quot;huh, this should be negative, will just use the abs function.&quot; However, these people will find ways of doing these evils even without exceptions.<br>
<br>Bonus: My favorite error-handling line of code at the company was a bit of VBA that went:<br><br>On Error Goto Hell<br><br>Michael<br></div></div></div>