I see. Thanks for the explanation.
Glen
--- Finn Bock <[EMAIL PROTECTED]> wrote:
> [Glen]
>
> > I'm not clear why you didn't derive
> > ValidationException from SAXParseException. I
> know
> > the locator is already present in FOPException,
> but
> > absent the subclass from SAXParseException,
[Glen]
I'm not clear why you didn't derive
ValidationException from SAXParseException. I know
the locator is already present in FOPException, but
absent the subclass from SAXParseException, it ends up
being a "different" Locator object, i.e., user code
that would handle a SAXParseException can't h
--- "Andreas L. Delmelle" <[EMAIL PROTECTED]>
wrote:
>
> You might want to try searching Xalan source code
> BTW: I don't think Xalan's
> actually throwing them anywhere, it merely *uses*
> them in the sense of
> 'catch and possibly throw a TransformerException' or
> define a method with
> 'throw
Finn,
I am more in agreement with your patch. +0 as-is.
--- Finn Bock <[EMAIL PROTECTED]> wrote:
[Finn]
>
> [Glen]
>
> > SPE might be considered the XML parsing
> > equivalent of a "syntax error" that would occur
> for a
> > code compilation error.
>
> Right, errors at the XML level.
>
It
Finn Bock wrote:
ValidateException is the right choice of exception when the FO file
doesn't follow the content model.
Nitpick: s/FO file/FO processor input document/
J.Pietschmann
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
> As the definition of its parent SAXException[1]
> states, "This class can contain basic error or warning
> information from either the XML parser *or the
> application*" So it can be used within FOP.
>
True, but I still
[Andreas]
It seems more about not throwing SAXParseExceptions,
but catching them and
throwing a FOPException instead. Isn't that the
issue? That a
'missingChildElementError' is actually not a
SAXParseException... because it
has nothing to do with SAX in itself
[Glen]
SAXParseExceptions would appea
Hello Andreas! (and others)
--- "Andreas L. Delmelle" <[EMAIL PROTECTED]>
wrote:
> > -Original Message-
> > From: Glen Mazza [mailto:[EMAIL PROTECTED]
> >
> >
>
> Hi Glen,
>
> > I'm confused--why is OK to throw SAXExceptions but
> not
> > its child SAXParseExceptions? With the latter,
Andreas L. Delmelle wrote:
> What about:
> - LayoutException
> - AreaException
> - RenderException
FWIW, this is exactly where FOray is headed. You and Finn are on the right
track.
Victor Mote
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
>
Hi Glen,
> I'm confused--why is OK to throw SAXExceptions but not
> its child SAXParseExceptions? With the latter, it
> just holds locator information necessary to pinpoint
> the problem for the user. Please elaborate
[Glen]
I'm confused--why is OK to throw SAXExceptions but not
its child SAXParseExceptions? With the latter, it
just holds locator information necessary to pinpoint
the problem for the user. Please elaborate.
The way I see it SAXException is the exception used to communicate
across the ContentHa
I'm confused--why is OK to throw SAXExceptions but not
its child SAXParseExceptions? With the latter, it
just holds locator information necessary to pinpoint
the problem for the user. Please elaborate.
Java gives us a large family of predefined exceptions
for use in our coding--I'm leery of proc
Big +1 for the FOPException subclasses. However, I wonder if
FOPException should have SAXException as its baseclass. Almost all FOP
exceptions will probably result in SAXExceptions as the whole processing
occurs between startDocument() and endDocument() SAX events, but most
FOP exceptions are not r
13 matches
Mail list logo
