Re: <index-out-of-bounds-error>

[Bruce Hoult <address@hidden>]

In article <3C3235CD.3040006@quiotix.com>, Jeffrey Siegal 
<jbs@quiotix.com> wrote:

> Bruce Hoult wrote:
> 
> > If you're catching the error a long way from where it is generated then 
> > why do you care exactly what the error was?  What are you going to do 
> > about it?
> 
> You might want to log it and categorize it using more information than 
> just a string.  If there is an identifyable subtype/heirarchy that 
> describes the error, it seems kind of silly to throw away that 
> information and turn it into something that is no longer machine readable.

It's not thrown away.  The <simple-error> contains not only the error 
text but also a reference to the actual collection object (vector, 
string etc) and the index value that caused the problem.


> (From your answer, though, it sounds like there isn't any such heirarchy 
> for errors in GD.)

GD is a work-in-progress.

There are currently specialized error classes for several things, 
including type errors and sealing errors.

As it's an open project, anyone is welcome to implement such a heirarchy 
if they feel a need for it.  They can even copy what Functional 
Developer does, if they want.  Which would then mean we could call it a 
standard :-)   (or persuade them to change if they did something silly)

It's probably only a few hours work.  grep for occurances of error(...) 
in the source, make a new function called e.g. "bounds-error(...)", and 
have that function do a "make(<bounds-error>, ...)", and add the new 
class <bounds-error> to d2c/runtime/dylan/condition.dylan (or elsewhere 
in the runtime library source...).

btw, calling a specialized function is better than calling make() 
directly because it generates less code at the error site, and there are 
a *lot* of them.

Rinse, lather, repeat...

-- Bruce