From: Intransition <transfire@...>
Date: 2012-01-21T23:22:31+09:00
Subject: Re: What defines an Error?

------=_Part_435_32296961.1327155748874
Content-Type: multipart/alternative; 
	boundary="----=_Part_436_4987820.1327155748874"

------=_Part_436_4987820.1327155748874
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit



On Saturday, January 21, 2012 7:12:42 AM UTC-5, short...@googlemail.com 
wrote:
>
> On Sat, Jan 21, 2012 at 12:46 AM, Marc Heiler <shev...@linuxmail.org> 
> wrote:
> >> Does narrowly defining the purpose of errors this way make sense?
> >
> > It seems to be too rigorous to me.
>
> It also does not work.  There might be only very few errors where
> there is just one condition for failure.  Normally the condition
> depends on the code _using_ the exception type.  Even for a TypeError
> things are not that clear: you may want to throw if the object in
> question is not one of _several_ types or you may want to throw if a
> specific method is not implemented etc.
>
Yea, I thought about it some more and came to a similar conclusion. 
Obviously one could create subclasses of TypeError for each of the 
particular cases you mention, but it would get pretty unwieldy in short 
order. The one that occurred to me that would probably get especially messy 
is IOError.

A compromise position could be used though, such that toplevel errors are 
open, with no such strict definition, but subclasses would have them. For 
example. my previously defined type error could be `class SpecificTypeError 
< TypeError`.

Even if not really practical, the question is still a bit intriguing. What 
kind of fine-grain error hierarchy would such a strict evaluational 
approach lead to? Is it (ultimately) completely definable?




------=_Part_436_4987820.1327155748874
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Saturday, January 21, 2012 7:12:42 AM UTC-5, short...@googlemail=
.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0=
.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">On Sat=
, Jan 21, 2012 at 12:46 AM, Marc Heiler &lt;<a>shev...@linuxmail.org</a>&gt=
; wrote:<br>&gt;&gt; Does narrowly defining the purpose of errors this way =
make sense?<br>&gt;<br>&gt; It seems to be too rigorous to me.<p>It also do=
es not work. &nbsp;There might be only very few errors where<br>there is ju=
st one condition for failure. &nbsp;Normally the condition<br>depends on th=
e code _using_ the exception type. &nbsp;Even for a TypeError<br>things are=
 not that clear: you may want to throw if the object in<br>question is not =
one of _several_ types or you may want to throw if a<br>specific method is =
not implemented etc.</p></blockquote><div>Yea, I thought about it some more=
 and came to a similar conclusion. Obviously one could create subclasses of=
 TypeError for each of the particular cases you mention, but it would get p=
retty unwieldy in short order. The one that occurred to me that would proba=
bly get especially messy is IOError.<br><br>A compromise position could be =
used though, such that toplevel errors are open, with no
 such strict definition, but subclasses would have them. For example. my=20
previously defined type error could be `class SpecificTypeError &lt; TypeEr=
ror`.<br></div><br>Even if not really practical, the question is still a bi=
t intriguing. What kind of fine-grain error hierarchy would such a strict e=
valuational approach lead to? Is it (ultimately) completely definable?<br><=
br><br><br>
------=_Part_436_4987820.1327155748874--

------=_Part_435_32296961.1327155748874--