RE: Error conditions

On Sun, 2007-03-11 at 22:40 -0400, Steve Carton wrote:

> I guess I feel like a middle ground is needed here. On the one hand, we
>  could spend a lot of time and effort whittling error categories into a
>  defined set (perhaps we need to TM just for the error and what they
>  relate too :-) and then imposing that requirement on developers. On
>  the other hand, there should be some specificity or we end up just
>  like the low-end XML parsers -- giving nothing helpful to the XML
>  author.

> Perhaps we can devise some form of hierarchical implementation requiremen=
t --=20
> specifying at the lowest level the detailed error conditions that should =
be=20
> trapped and how they should be reported and then one (or more) higher lev=
els=20
> of broader specificity, enabling developers to implement an easier error=20
> condition set at first.

This was all discussed. There was VERY strong resistance from some
parties to specify ANY distinct set of defined errors, despite that
being the convention used by many recent languages (XQuery, XSLT, ...).
So the resolution was that there is NO such list (or hierarchy).

What I will do at some point is to inspect my prototype implementation
to get an clear overview of the possible cases. I'll post it here.

\rho

> -----Original Message-----
> From: [email protected] [mailto:tmql-wg-bounces@isotopicma=
ps.org] On Behalf Of Lars Marius Garshol
> Sent: Saturday, March 10, 2007 9:35 AM
> To: [email protected]
> Subject: Re: [tmql-wg] Error conditions
>=20
>=20
> * Robert Barta
> >
> > A bit, yes. At least we would have a list (maybe 10?, just guessing)=20
> > errors named.
>=20
> We could, but IMHO it's more important to finish TMQL than to include thi=
s list. Anything we add to the language extends the time it takes to finish=
.
>=20
> * Lars Marius Garshol
> >
> >  - causes problems for implementors, because error situations tend to
> >    be highly dependent on implementation strategy, and
>=20
> * Robert Barta
> >
> > OK, that should actually not happen. If the query is valid, then a=20
> > processor MUST perform, regardless how it is implemented.
>=20
> Yes, and if it is an error, the processor MUST NOT perform. So we agree o=
n that. What I meant is that it's more work for an implementation to distin=
guish error situation A from error situation B than it is to simply say "th=
is query is wrong". Of course, better error reports make for a better query=
 processor, but that's a choice for the developer to make. Some XML parsers=
 (=C6lfred, XP) simplify things by simply reporting everything as a "syntax=
 error".
>=20
> My experience is also that if you choose a different implementation strat=
egy from others you may find distinguishing between errors A and B quite a =
bit harder.
>=20
> --Lars M.
>=20
>=20
> _______________________________________________
> tmql-wg mailing list
> [email protected]
> http://www.isotopicmaps.org/mailman/listinfo/tmql-wg
> _______________________________________________
> tmql-wg mailing list
> [email protected]
> http://www.isotopicmaps.org/mailman/listinfo/tmql-wg
>=20