# [tmql-wg] Error conditions

Robert Barta rho at devc.at
Sat Jul 14 06:04:23 EDT 2007

On Thu, Mar 29, 2007 at 01:55:24PM +1000, Robert Barta wrote:
> 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 requirement --
> > specifying at the lowest level the detailed error conditions that should be
> > trapped and how they should be reported and then one (or more) higher levels
> > of broader specificity, enabling developers to implement an easier error
> > 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.

The latest version (to appear soon in a cinema near you) contains:

a) Syntax errors obviously are errors.

b) The rest are all during evaluation:

- item reference cannot be resolved in effective map (4.2)
- ontology topic does not have subject indicator (4.2)
- item identifier cannot be resolved in effective map (4.3:1)
- IRI cannot be resolved as subject identifier in effective map (4.3:2)
- index overflow in tuple extraction (4.8.1)
- XML fragment not well-formed (4.9)
- function reference cannot be resolved in effective map (4.12)
- function parameter mismatch 4.12:1, 4.12:2
- variable not bound to a value (4.13.1)
- OFFSET or LIMIT value not non-negative integer (6.4)
- role type does not evaluate to a topic item (6.6.4)
- role player does not evaluated to a topic item (6.6.4)

If someone wants to re-raise the issue that these error conditions
should be explicitly named, then this is the time. Montreal is the
next meeting.

\rho

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