Re: Minor conditions cleanup
Carl Gay <[email protected]> Mon, 19 May 2014 15:29:34 -0400
| Newsgroups | gmane.comp.lang.dylan.gwydion.devel |
|---|---|
| Message-ID | <CALekcH2m=WV+sgrntoo_zv_RDgdkt=cbuXijO4xhtRWChd=Kgw@mail.gmail.com> |
--===============0156643874==
Content-Type: multipart/alternative; boundary=001a113457dc827af804f9c5c816
--001a113457dc827af804f9c5c816
Content-Type: text/plain; charset=UTF-8
[I have to admit up front that this is not the most important thing we
could be doing, given that most correct programs shouldn't be catching
<key-error> anyway. This is just a little messy area that caught my eye.]
Having the more specific error classes is fine with me. My main goal is to
have a coherent set of errors signaled by the collections code because I
noticed that the errors signaled by element() didn't make a lot of sense.
They all basically end up being related to bad keys, hence <key-error>.
If I look at it a little more broadly, something like this makes sense to
me:
Current hierarchy:
<simple-error>
<empty-collection-error>
<iteration-error>
<not-found-error>
<invalid-index-error>
<subscript-out-of-bounds-error>
New hierarchy:
<simple-error>
<collection-error>
<iteration-error> // only signaled by accumulators
<key-error>
<empty-collection-error>
<subscript-error>
You may wonder why it makes sense for <empty-collection-error> to be a
subclass of <key-error>. The reason is because it is only signaled when
the operation (pop, pop-last, reduce1) is calling element() with an invalid
key.
This all doesn't really mean much though, given that none of these errors
are exported. I propose that we export <collection-error> and <key-error>
at least. I'm still unsure of the usefulness of <empty-collection-error>
and <subscript-error> given that the error messages themselves are clear.
Once they're exported t's hard to go back.
On Sun, May 18, 2014 at 11:24 AM, Bruce Mitchener <[email protected]
> wrote:
> Hey Carl,
>
> Sorry for the long delay in responding to this.
>
> I think that it would be a good chance to have a common base class (be it
> <key-error> or <collection-error> or whatever).
>
> However, I do like having the more specific and descriptive errors, so I'd
> rather not see those go away.
>
> Cheers,
>
> - Bruce
>
>
> On Mon, May 12, 2014 at 2:53 AM, Carl Gay <[email protected]> wrote:
>
>> I'd like to make a minor cleanup to the condition classes signaled for
>> collections code. Please let me know if you object to these changes or if
>> you would suggest specific changes. If there are no objections in
>> principle I can send a patch for review to the list.
>>
>> Summary:
>>
>> - All collection access that involves a bad key of any kind will
>> signal a subclass of <key-error> instead of the current disjoint set of
>> conditions: <not-found-error>, <invalid-index-error>,
>> <subscript-out-of-bounds-error>, and <empty-collection-error>. This
>> includes
>> - invalid index for sequence
>> - invalid number of array subscripts (rank errors)
>> - reduce1, pop, first, second, last, etc on an empty (or too
>> small) collection
>> - element(<set>, value) if value not present
>>
>> This would *not* cover, for example, element(<string-table>, <integer>)
>> and other type errors, as it looks to me like that would involve inserting
>> run-time checks that would slow down access. (I only took a very brief
>> look at this. I suspect these cases currently signal <type-error>.)
>>
>> The main point is to have one shared condition class for invalid
>> collection accesses. I personally don't see a lot of advantage in keeping
>> the existing condition classes around as subclasses of <key-error> (except
>> perhaps <subscript-error>, see diff), but I'd like to hear what others
>> think.
>>
>
> _______________________________________________
> hackers mailing list
> [email protected]
> https://lists.opendylan.org/mailman/listinfo/hackers
>
>
--001a113457dc827af804f9c5c816
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>[I have to admit up front that this is not the most i=
mportant thing we could be doing, given that most correct programs shouldn&=
#39;t be catching <key-error> anyway. =C2=A0This is just a little mes=
sy area that caught my eye.]</div>
<div><br></div>Having the more specific error classes is fine with me. =C2=
=A0My main goal is to have a coherent set of errors signaled by the collect=
ions code because I noticed that the errors signaled by element() didn'=
t make a lot of sense. =C2=A0They all basically end up being related to bad=
keys, hence <key-error>.<div>
<br></div><div>If I look at it a little more broadly, something like this m=
akes sense to me:</div><div><br></div><div>Current hierarchy:<br></div><div=
><div class=3D"gmail_extra"><font face=3D"courier new, monospace"><simpl=
e-error></font></div>
<div class=3D"gmail_extra"><font face=3D"courier new, monospace">=C2=A0 <=
;empty-collection-error></font></div><div class=3D"gmail_extra"><font fa=
ce=3D"courier new, monospace">=C2=A0 <iteration-error></font></div><d=
iv class=3D"gmail_extra">
<font face=3D"courier new, monospace">=C2=A0 <not-found-error></font>=
</div><div class=3D"gmail_extra"><font face=3D"courier new, monospace">=C2=
=A0 =C2=A0 <invalid-index-error></font></div><div class=3D"gmail_extr=
a"><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 <subscript=
-out-of-bounds-error></font></div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><div>New hi=
erarchy:</div><div><font face=3D"courier new, monospace"><simple-error&g=
t;</font></div><div><font face=3D"courier new, monospace">=C2=A0 <collec=
tion-error></font></div>
<div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 <iteration-erro=
r> =C2=A0// only signaled by accumulators</font></div><div><font face=3D=
"courier new, monospace">=C2=A0 =C2=A0 <key-error></font></div><div><=
font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 <empty-collect=
ion-error></font></div>
<div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 <subscri=
pt-error></font></div><div><br></div><div>You may wonder why it makes se=
nse for <empty-collection-error> to be a subclass of <key-error>=
;. =C2=A0The reason is because it is only signaled when the operation (pop,=
pop-last, reduce1) is calling element() with an invalid key.</div>
<div><br></div><div>This all doesn't really mean much though, given tha=
t none of these errors are exported. =C2=A0I propose that we export <col=
lection-error> and <key-error> at least. =C2=A0I'm still unsur=
e of the usefulness of <empty-collection-error> and <subscript-err=
or> given that the error messages themselves are clear. =C2=A0Once they&=
#39;re exported t's hard to go back.</div>
<div><br></div><div></div></div><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote">On Sun, May 18, 2014 at 11:24 AM, Bruce Mitchener <span dir=3D"l=
tr"><<a href=3D"mailto:[email protected]" target=3D"_blank" clas=
s=3D"cremed">[email protected]</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"=
gmail_quote">
Hey Carl,</div><div class=3D"gmail_quote"><br>Sorry for the long delay in r=
esponding to this.</div><div class=3D"gmail_quote"><br></div><div class=3D"=
gmail_quote">
I think that it would be a good chance to have a common base class (be it &=
lt;key-error> or <collection-error> or whatever).</div><div class=
=3D"gmail_quote"><br></div><div class=3D"gmail_quote">However, I do like ha=
ving the more specific and descriptive errors, so I'd rather not see th=
ose go away.</div>
<div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Cheers,</di=
v><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">=C2=A0- B=
ruce</div><div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quo=
te">
<br></div><div class=3D"gmail_quote">
On Mon, May 12, 2014 at 2:53 AM, Carl Gay <span dir=3D"ltr"><<a href=3D"=
mailto:[email protected]" target=3D"_blank" class=3D"cremed">carlgay@gmail.=
com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2=
04);border-left-style:solid;padding-left:1ex">
<div dir=3D"ltr"><div>I'd like to make a minor cleanup to the condition=
classes signaled for collections code. =C2=A0Please let me know if you obj=
ect to these changes or if you would suggest specific changes. =C2=A0If the=
re are no objections in principle I can send a patch for review to the list=
.</div>
<div><br></div><div>Summary:</div><div><ul><li>All collection access that i=
nvolves a bad key of any kind will signal a subclass of <key-error> i=
nstead of the current disjoint set of conditions: <not-found-error>, =
<invalid-index-error>, <subscript-out-of-bounds-error>, and <=
;empty-collection-error>. =C2=A0This includes<br>
</li><ul><li>invalid index for sequence</li><li>invalid number of array sub=
scripts (rank errors)</li><li>reduce1, pop, first, second, last, etc on an =
empty (or too small) collection</li><li>element(<set>, value) if valu=
e not present</li>
</ul></ul>This would <b>not</b> cover, for example, element(<string-tabl=
e>, <integer>) and other type errors, as it looks to me like that =
would involve inserting run-time checks that would slow down access. =C2=A0=
(I only took a very brief look at this. =C2=A0I suspect these cases current=
ly signal <type-error>.)<br>
</div><div><br></div><div>The main point is to have one shared condition cl=
ass for invalid collection accesses. =C2=A0I personally don't see a lot=
of advantage in keeping the existing condition classes around as subclasse=
s of <key-error> (except perhaps <subscript-error>, see diff), =
but I'd like to hear what others think.</div>
</div></blockquote></div></div></div></div>
<br>_______________________________________________<br>
hackers mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank" class=3D"c=
remed">[email protected]</a><br>
<a href=3D"https://lists.opendylan.org/mailman/listinfo/hackers" target=3D"=
_blank" class=3D"cremed">https://lists.opendylan.org/mailman/listinfo/hacke=
rs</a><br>
<br></blockquote></div><br></div></div></div>
--001a113457dc827af804f9c5c816--
--===============0156643874==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
hackers mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/hackers
--===============0156643874==--