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

------=_Part_291_1344957.1327156646634
Content-Type: multipart/alternative; 
	boundary="----=_Part_292_22573229.1327156646634"

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



On Friday, January 20, 2012 6:46:11 PM UTC-5, Marc Heiler wrote:
>
> > Does narrowly defining the purpose of errors this way make sense?
>
> It seems to be too rigorous to me.
>
> I like to keep errors very small and self-descriptive whenever possible.
>
> What I am playing with is to, rather than subclass, perhaps use an
>
> Exception.new('too few arguments') if @found_error
>
> Or something like that, rather than a specific raise(). But I am 
> strange. ;)
>

:-) Yea, it does seem strange to define rather empty classes. I've wondered 
myself it it would not have just been a whole lot easer if Ruby used symbol 
names instead of classes. But the classes provide a hierarchy, so that's 
the reason. As a bonus it allows us to customize the default error message 
in the class definition. Analysis and testing tools, may then use those 
error types to good effect. So I would advise in your example, to try to 
match up the closest available error, i.e.

  ArgumentError.new('too few arguments') if @found_error

I've actually been able to do a little more with error classes too then I 
suspect Matz had any inkling of when he first crated them, indeed there are 
some restrictive "interface contracts", it you will, that make it not ideal 
in some instances. But working around those, the ability to extend 
exception classes has allowed for some nifty approaches to testing.


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

<br><br>On Friday, January 20, 2012 6:46:11 PM UTC-5, Marc Heiler wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-l=
eft: 1px solid rgb(204, 204, 204); padding-left: 1ex;">&gt; Does narrowly d=
efining the purpose of errors this way make sense?<p>It seems to be too rig=
orous to me.</p><p>I like to keep errors very small and self-descriptive wh=
enever possible.</p><p>What I am playing with is to, rather than subclass, =
perhaps use an</p><p>Exception.new('too few arguments') if @found_error</p>=
<p>Or something like that, rather than a specific raise(). But I am <br>str=
ange. ;)</p></blockquote><div><br>:-) Yea, it does seem strange to define r=
ather empty classes. I've wondered myself it it would not have just been a =
whole lot easer if Ruby used symbol names instead of classes. But the class=
es provide a hierarchy, so that's the reason. As a bonus it allows us to cu=
stomize the default error message in the class definition. Analysis and tes=
ting tools, may then use those error types to good effect. So I would advis=
e in your example, to try to match up the closest available error, i.e.<br>
<br>
&nbsp; ArgumentError.new('too few arguments') if @found_error<br>
<br>I've actually been able to do a little more with error classes too then=
 I suspect Matz had any inkling of when he first crated them, indeed there =
are some restrictive "interface contracts", it you will, that make it not i=
deal in some instances. But working around those, the ability to extend exc=
eption classes has allowed for some nifty approaches to testing.<br><br></d=
iv>
------=_Part_292_22573229.1327156646634--

------=_Part_291_1344957.1327156646634--