RE: Exception hierarchy.

[Glen Mazza]

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, it
> > just holds locator information necessary to
> pinpoint
> > the problem for the user.  Please elaborate.
> >
> 
> 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 

SAXParseExceptions would appear to be for errors that
occur during the SAX parsing of an XML document (as a
result of a user supplying an invalid XML document). 
It is not for errors that occur within the
implementation of the SAX processor (e.g., Xalan)
itself.  SPE might be considered the XML parsing
equivalent of a "syntax error" that would occur for a
code compilation error.  

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.

[1]
http://xml.apache.org/xalan-j/apidocs/org/xml/sax/SAXException.html


--it's a
> violation of a definition as
> formulated in the XSL-FO Rec. The error is treated
> and reported as being a
> SAXParseException only because the latter offers the
> convenience of a
> locator, but it should actually be something like

No, because the SAXParseException is for such
validation errors, regardless of what you're parsing. 
Learn once, use everywhere:  Batik, FOP, Cocoon, Axis,
etc., etc.  (Also, as a minor additional benefit, it
helps pluggability if all XSL processors adopted
SAXParseException instead of each of us coming up with
our own name for this.)

> the suggested
> 'ValidateException', or maybe something like
> 'FOParseException'.
> 

Using that logic, a SAXParseException would never be
used anywhere, because it is SAX usually used to
validate the XML document.  If it's no good for FOP,
then it would be no good for Batik, and Cocoon, and
Axis, and then we're back to rarely using Java
exceptions directly in one's coding. 
SAXParseException is there for a purpose:  to be used,
it's already coded and documented!


> Throwing a SAXParseException actually seems more
> confusing to the end-user
> (--he/she who, on average, reads little more than
> the first two lines of the
> stack trace :-) )
> 

Maybe not, because a SAXParseException has the benefit
of the user knowing it already (and if they don't know
it, they will learn it *now*, and get to apply this
knowledge for future parsing of other languages.) 
Also, our SAXParseExceptions each have detailed error
messages telling them what the problem is.  (The stack
trace they usually won't see anyway, unless they
choose to run in debug mode.)



> What's wrong with an app having its own set of
> particular exceptions
> reflecting its overall design, according to 'what
> can go wrong and where'?
> 

Excellent question.  The reason is that exceptions are
for the benefit of the user using the software, and
he/she has usually no internal knowledge of the
software product itself.  The user doesn't know about
FO trees, area trees, layout, renderers--this is all
our language that is collectively a black box to the
user.  Furthermore, users don't care *where* the error
occurred inside the black box (advanced users have the
stack trace anyway), they do want to know *what* went
wrong though, so they can group those *what's*
together and report on them in a common manner.

For example, I see two main errors that can occur with
FOP:

1.) syntax error:  elements not following (a) proper
ordering or (b) invalid values for properties.  These
should raise a SAXParseException, with IMHO not
*necessarily* a need to differentiate between the two
because they both imply the same problem:  badly
written stylesheet, as well as the same solution:
fix/redo your stylesheet.

2.) file not found errors.  Here, the stylesheet is
fine, but it can't find the various .gif's or other
hardcoded filenames within it.  These should raise a
FileNotFoundException, to indicate to the user they
need to relocate files.  (I'd like Finn BTW to
elaborate why he feels FNFE would not be a good idea 
for FOP, I don't see the problem with it.)

There may be minor ones besides these, that most
external users can trap with a regular Exception at
the end.

This way, user's embedded code would be (pseudocode):

try {
  driver.run();
} catch (SAXParseException) {
// tell user there's a bug in the stylesheet
} catch (FileNotFoundException) {
// tell user a file can't be found
} catch (Exceptiion) {
// anything else
}

> What about:
> - LayoutException
> - AreaException
> - RenderException
> ...
> 

This would fail, because there's no way to
identify/group errors 

page-number-citation problem

[Randy Ouellette]

We are having an issue with using the page-number-citation for outputting
the page-number for those pages that are inside a page-sequence when the
number is restarted (initial-number="1"). We are trying to output a
page-number in a TOC but cannot get a value.

Is there going to be a fix for this type of issue in the future? Is there
anything we can do in the source code to enable this?

Please let us know, we are working on a project for Department of Defense
and need this information ASAP.

Regards,

_
Randy Ouellette
DynaMark Solutions Inc.
Ph.: (403) 730-0808
Fax: (403) 730-0832
web: www.dynamarksolutions.com
mail: [EMAIL PROTECTED]
_

RE: Exception hierarchy.

[Victor Mote]

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

Re: DO NOT REPLY [Bug 31206] - [PATCH] Improvements over the new line breaking algorithm

[Simon Pepping]

Luca,

I will try to look at your patch later this week.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: → in DnI documentation

[Simon Pepping]

Clay,

Sorry for not answering earlier. I have a couple of other things to do
these weeks.

On Thu, Oct 21, 2004 at 02:25:12PM -0700, Clay Leeds wrote:
> I'd also like to resolve the error in Forrest if possible, so the rest 
> of this POST deals with that.
> 
> I suspect the problem is related to the fact that properties.xml 
> references a dtd like this:
> 
> 
> 
> A couple of things I note here:
> 1. It's commented out

It is commented out so it should not have any influence. It is there
so that I can uncomment and use it during editing.

> 2. this is a relative/local link, but the 'docbookx.dtd' is not local
>(I also tried 
> 'http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd' and
>'http://www.oasis-open.org/docbook/xml/4.2/' and as expected neither 
> works.)

Because it is only used during editing I have not bothered to make it
absolute. The file book.xml has an absolute path for the DTD, and that
is the one that matters.

> 3. fwiw, iso-num.ent is at
>http://www.oasis-open.org/docbook/xml/4.2/ent/iso-num.ent

The dtd that one uses, should have correct relative links to the
entities files. In that way they are loaded without anyone having to
bother about them.

> I'm not very 'up' on DocBook, so this may be how it's 'supposed' to 
> work. Nevertheless, → is the only thing in 'properties.xml' that 
> doesn't validate during the /forrest/ run (unless I replace → with 
> → or →).

Once the document and the stylesheets have been written, nothing is
very docbook specific. Only correct absolute paths or good catalogs
matter at that stage. Nevertheless, docbook is a very complex DTD that
uses the whole DTD machinery. I am glad it works.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

RE: Exception hierarchy.

[Andreas L. Delmelle]

> -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.
>

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 --it's a violation of a definition as
formulated in the XSL-FO Rec. The error is treated and reported as being a
SAXParseException only because the latter offers the convenience of a
locator, but it should actually be something like the suggested
'ValidateException', or maybe something like 'FOParseException'.

Throwing a SAXParseException actually seems more confusing to the end-user
(--he/she who, on average, reads little more than the first two lines of the
stack trace :-) )

> Java gives us a large family of predefined exceptions
> for use in our coding--I'm leery of proclamations of
> them being No Good and that each and every Java
> application must re-invent their own exceptions
> instead.  That just seems sloppy.
>

Exceptions are very OK indeed, but I think that merely using the prefined
ones is, in a way, missing the point. They were designed to be 'thrown'
around as well as 'extended'. One can act as a sort of collector for all
other types, centralizing error-handling and providing a tidy stack trace,
with immediate indicators as to where the problem poses itself --in terms of
location in the process as well as a possible location in a file...

What's wrong with an app having its own set of particular exceptions
reflecting its overall design, according to 'what can go wrong and where'?

What about:
- LayoutException
- AreaException
- RenderException
...

+1 for Finn's suggestion.

Cheers,

Andreas

Re: Exception hierarchy.

[Finn Bock]

[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 ContentHandler event methods. And SAXParseException is used 
to communicate an actual error during parsing of XML. That is what the 
exception type specify.

And BTW, the patch does not throw any SAXExceptions.
Java gives us a large family of predefined exceptions
for use in our coding--I'm leery of proclamations of
them being No Good and that each and every Java
application must re-invent their own exceptions
instead.  That just seems sloppy.
But the java exceptions are Very Good. There is just isn't any of them 
that specifies an error found during XSL:FO validation or found during 
property evaluation of XSL:FO expressions.

Glen  (who wanted to get rid of FOPException and just
rely on the Java-defined exceptions)
IMHO reusing SAXParseException is exactly as wrong as reusing f.ex. 
FileNotFoundException, which is another fine exception, just not suited 
for use from within FO tree building.

regards,
finn

Re: Exception hierarchy.

[Glen Mazza]

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 proclamations of
them being No Good and that each and every Java
application must re-invent their own exceptions
instead.  That just seems sloppy.

Glen  (who wanted to get rid of FOPException and just
rely on the Java-defined exceptions)

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> 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 really SAX-related. I can't
> pinpoint it, yet, but
> it somehow doesn't feel right. This is not a veto to
> this change. I'm
> only stating what I'm thinking. Consider it a +0 for
> the proposed
> hierarchy. I agree however, that SAXParseExceptions
> shouldn't be thrown
> from within FOP.
> 
> On 26.10.2004 20:18:15 Finn Bock wrote:
> > I would like to make some changes to the
> exceptions used in tree building.
> > 
> > First, I dislike throwing SAXParseException from
> within FOP. In my 
> > opinion SAXParseException are for reporting
> problems during the parsing 
> > of XML, not for reporting subsequent problems with
> the FO tree.
> > 
> > Second, the exceptions used in FOP should form a
> structure where 
> > concrete subclass exception are thrown and a
> common superclass can be 
> > used for catching all the different exceptions.
> > 
> > My proposal for the exception hierarchy look like
> this:
> > 
> > - SAXException
> >- FOPException
> >  - ValidateException
> >  - PropertyException
> > 
> > Putting all our exceptions into one hierarchy that
> inherit from 
> > SAXException helps reduce the number of wrapped
> exception.
> > 
> > I've uploaded a patch which changes the FO tree
> building and property 
> > code. The benefit of the patch is the reduced
> number of blind catches:
> > 
> >  } catch (XXXException e) {
> >  // log.error(e);
> >  }
> > 
> > Any objections?
> 
> 
> 
> Jeremias Maerki
> 
> 

Re: Exception hierarchy.

[Jeremias Maerki]

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 really SAX-related. I can't pinpoint it, yet, but
it somehow doesn't feel right. This is not a veto to this change. I'm
only stating what I'm thinking. Consider it a +0 for the proposed
hierarchy. I agree however, that SAXParseExceptions shouldn't be thrown
from within FOP.

On 26.10.2004 20:18:15 Finn Bock wrote:
> I would like to make some changes to the exceptions used in tree building.
> 
> First, I dislike throwing SAXParseException from within FOP. In my 
> opinion SAXParseException are for reporting problems during the parsing 
> of XML, not for reporting subsequent problems with the FO tree.
> 
> Second, the exceptions used in FOP should form a structure where 
> concrete subclass exception are thrown and a common superclass can be 
> used for catching all the different exceptions.
> 
> My proposal for the exception hierarchy look like this:
> 
> - SAXException
>- FOPException
>  - ValidateException
>  - PropertyException
> 
> Putting all our exceptions into one hierarchy that inherit from 
> SAXException helps reduce the number of wrapped exception.
> 
> I've uploaded a patch which changes the FO tree building and property 
> code. The benefit of the patch is the reduced number of blind catches:
> 
>  } catch (XXXException e) {
>  // log.error(e);
>  }
> 
> Any objections?



Jeremias Maerki

Exception hierarchy.

[Finn Bock]

Hi Team,
I would like to make some changes to the exceptions used in tree building.
First, I dislike throwing SAXParseException from within FOP. In my 
opinion SAXParseException are for reporting problems during the parsing 
of XML, not for reporting subsequent problems with the FO tree.

Second, the exceptions used in FOP should form a structure where 
concrete subclass exception are thrown and a common superclass can be 
used for catching all the different exceptions.

My proposal for the exception hierarchy look like this:
- SAXException
  - FOPException
- ValidateException
- PropertyException
Putting all our exceptions into one hierarchy that inherit from 
SAXException helps reduce the number of wrapped exception.

I've uploaded a patch which changes the FO tree building and property 
code. The benefit of the patch is the reduced number of blind catches:

} catch (XXXException e) {
// log.error(e);
}
Any objections?
regards,
finn

DO NOT REPLY [Bug 31899] - [PATCH] Exception hierarchy.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31899

[PATCH] Exception hierarchy.





--- Additional Comments From [EMAIL PROTECTED]  2004-10-26 18:21 ---
Created an attachment (id=13223)
Unified diff against head

DO NOT REPLY [Bug 31899] New: - [PATCH] Exception hierarchy.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31899

[PATCH] Exception hierarchy.

   Summary: [PATCH] Exception hierarchy.
   Product: Fop
   Version: 1.0dev
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


This patch changes the exceptions used during tree building. 
The hierarchy looks like this:

- SAXException
  - FOPException
- ValidateException
- PropertyException

Most methods that can cause exception now declares that exception instead
of catching them and continuing.

Re: meaning of Area.TreeExt interface

[Finn Bock]

[Glen]
OK, I'd like to 

1) rename TreeExt to OffDocumentItem (to clarify what
it's really for)  

2) change it from an interface to an abstract base
class.  

3.) Have this base class hold the "when" parameter for
when this ODI is to be generated, so the "when" does
not need to be hardcoded into AreaTreeHandler as it is
currently for PDF Bookmarks.  (Helps with
extensibility.)
4.) Rename Renderer.renderTreeExtension() to
Renderer.processOffDocumentItem().  

Any problems with this?
No.
regards,
finn

Re: meaning of Area.TreeExt interface

[Glen Mazza]

--- Finn Bock <[EMAIL PROTECTED]> wrote:
> [Glen]
> 
> > Actually, to clarify what I wrote: why do we need
> an
> > extension interface (TreeExt) for objects placed
> > outside the document (pdf bookmarks/metadata),
> while
> > *not* needing one for extension objects that end
> up
> > placed *on* the document?
> 
> You subclass Area for elements on the document and
> TreeExt for elements 
> outside the document.
> 

OK, I'd like to 

1) rename TreeExt to OffDocumentItem (to clarify what
it's really for)  

2) change it from an interface to an abstract base
class.  

3.) Have this base class hold the "when" parameter for
when this ODI is to be generated, so the "when" does
not need to be hardcoded into AreaTreeHandler as it is
currently for PDF Bookmarks.  (Helps with
extensibility.)

4.) Rename Renderer.renderTreeExtension() to
Renderer.processOffDocumentItem().  

Any problems with this?

Thanks,
Glen

Re: meaning of Area.TreeExt interface

[Glen Mazza]

--- Finn Bock <[EMAIL PROTECTED]> wrote:
> 
> [Glen]
> 
> > Finn, ***be very careful***, the definition of
> tree
> > extension was #2, *not* #1 (see previous email). 
> I
> > don't like its name, it should be OutOfAreaObject
> or
> > something like that.  
> 
> And why shouldn't extensions be allowed to create
> OutOfAreaObjects? Some 
> extension writers will needed that just like the
> author of fox:bookmarks 
> needed it.
> 

OK, now I see.  Thanks.

Glen

[GUMP@brutus]: Project xml-fop (in module xml-fop) failed

[Sam Ruby]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project xml-fop has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 6 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- xml-fop :  XSL-FO (Formatting Objects) processor


Full details are available at:
http://brutus.apache.org/gump/public/xml-fop/xml-fop/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [fop.jar] identifier set to project name
 -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop/build/classes]
 -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop/build/test-classes]
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/xml-fop/xml-fop/gump_work/build_xml-fop_xml-fop.html
Work Name: build_xml-fop_xml-fop (Type: Build)
Work ended in a state of : Failed
Elapsed: 32 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only gump 
[Working Directory: /usr/local/gump/public/workspace/xml-fop]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/xml-fop/build/classes:/usr/local/gump/public/workspace/xml-fop/build/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/xml-batik/batik-26102004/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-26102004/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-26102004/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-26102004/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-26102004/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-26102004/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-26102004/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-26102004/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-26102004/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-26102004/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-26102004/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-26102004/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-26102004/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-26102004/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-26102004/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-26102004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-26102004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-26102004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-26102004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jakarta-commons/io/dist/jakarta-commons-io-26102004.jar:/usr/local/gump/public/workspace/jfor/dist/lib/jfor-26102004.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar
-

junit:
[javac] Compiling 31 source files to 
/usr/local/gump/public/workspace/xml-fop/build/test-classes
[javac] This version of java does not support the classic compiler; upgrading to 
modern
[javac] 
/usr/local/gump/public/workspace/xml-fop/test/java/org/apache/fop/util/ASCII85InputStreamTestCase.java:25:
 w