Bug 19914 - Need more informative error response from FOP
Summary: Need more informative error response from FOP
Status: CLOSED DUPLICATE of bug 5010
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: general (show other bugs)
Version: 0.20.5
Hardware: PC other
: P3 enhancement
Target Milestone: ---
Assignee: fop-dev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-05-14 09:21 UTC by Richard Barrett
Modified: 2012-04-01 13:47 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Barrett 2003-05-14 09:21:59 UTC
Using FOP in conjunction with Altova (http://www.altova.com) xmlspy 5.4

Error reported to Altova and identified by them as being due to missing xsl:fo 
commands leads to a modal dialogue saying:

    Output of external XSL Convertor
    [ERROR} Unknown formatting object ^html
    [ERROR] java.lang.NullPointerException

Altova say this uninformative message, which is of limited value in diagnosing 
the user error and appropriate corrective action, is dwon to FOP.

More problem oriented and appropriate error message would be appreciated, by me 
at least.
Comment 1 Jeremias Maerki 2003-05-14 09:33:19 UTC
Ok, let's do it this way: I'll tell you what's wrong and you tell me what the 
error message should look like in your opinion and we'll see if we can improve 
on that.

You've tried to convert HTML to PDF, PS or whatever. FOP doesn't understand 
HTML. If you want to process HTML you have to convert it to XSL-FO first, 
because XSL-FO (and SVG) is what FOP understands.

Basically the error message says: It has encountered a tag "html" (in the 
default namespace) which is an unknown formatting object. A valid formatting 
object would be "root" or "page-sequence".

The NullPointerException afterwards can just be a subsequent error because FOP 
cannot recover from your "html" tag.
Comment 2 Richard Barrett 2003-05-14 13:37:53 UTC
But that is exactly NOT what the error message says. Its what you say it means 
because you know the code and how it works.

Lets make an assumption; some of the people who will use this software are not 
programming experts on this code and either do not have the time or do not have 
inclination to be so. 

The software discovers that the input data it is receiving is not what it 
expects. After all, the software does have some input data validation in the 
code, or does everything just blindly fall to an outer exception handler?

The error response delivered is the equivalent to a compiler saying:

    Found error in source file.

Factually correct but of limited utility.

How about a message that says something like:

"Input data error at line xxx of input file yyy. Expected ..., got ..."

where ... are bits of English that hint at the mistake the user has made in 
creating his input with maybe even an allusion as to how to correct the mistake 
they have made.

In the case I tripped over, something like would be a bit more meaningful:

Input data error at line 5 of xyz.xsl. Expected "fo:root or fo:page-sequence" 
tag, got "html" tag

That way non-programmers might be able to avoid troubling developers with 
stupid questions. That is of course, on the assumption you want people other 
than programmers to use this software.

Comment 3 J.Pietschmann 2003-05-14 14:58:55 UTC
Some general problems:
- What you think of as source is not the source for the FO processor. There
  is no way to get a source file name or line number at the point where the
  error was detected if you supply XML+XSLT instead of a FO file.
- At the point where the error is detected, there are no hints available which
  cold restrict possible choices down to a range an uninitiated could possibly
  understand. Technically, the code looks into a table with all possible names,
  and if the name isn't found, the "Unknonwn formatting object" message is
  generated. I doubt that dumping 5 pages or so of known names is of much
  help. Restricting the message to "expected element from namespace <foo>,
  <bar> or <baz>" is probably not of much help either, because the namespace
  strings tend to be unwieldy, and people feeding wrong elements to FOP tend
  to be agnostic about namespaces anyway.
These restrictions would basically force to trim down your proposal to
  Input data error. Got "html" tag
which is not much of an improvement.
We can hardcode a more sensible error response if a <html> element is found,
because it appears to be common among uninformed newbies to feed a
HTML-generating style sheet to FOP. However, this wouldn't help in cases
where the problem was triggered by problems in the style sheet, misspellings
or simply by people doing unanticipated stupid things which don't quite
match the hardcoded symptoms.

*** This bug has been marked as a duplicate of 5010 ***
Comment 4 Jeremias Maerki 2003-05-14 15:12:45 UTC
Just a moment: I have a little improvement finished in a few minutes. It will 
aproximately look like this:

[ERROR] Unsupported element encountered: bad (Namespace: default). Source 
context: file:/D:/FOP/temp/bad.fo (line: 11, col: 13)
[ERROR] Expected XSL-FO (root, page-sequence, etc.), SVG (svg, rect, etc.) or 
elements from another supported language.
[ERROR] Unsupported element encountered: stuff (Namespace: 
http://www.evil.com). Source context: file:/D:/FOP/temp/bad.fo (line: 12,
 col: 53)

or:

[ERROR] Unsupported element encountered: stuff (Namespace: 
http://www.evil.com). Source context: unavailable

The verbose message will come only once. That should improve it a bit.
Comment 5 Richard Barrett 2003-05-14 20:09:02 UTC
Looks like a real improvement. Thankyou.
Comment 6 Glenn Adams 2012-04-01 13:47:51 UTC
batch transition to closed remaining pre-FOP1.0 resolved bugs