cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robin Green" <gree...@hotmail.com>
Subject Re: Cocoon 2 suggestions
Date Sat, 15 Apr 2000 13:54:21 GMT
Pier wrote:

>It's not a question of error handling only for XSP... I believe that
>better error handling should be put throughout the code...

Yes, see my earlier post on custom error pages as well.

>I'm trying to come up with a set of exceptions and rules on how to
>handle them, so that we could get better "feelings" on what happens when
>something goes wrong...
>
>On a sidenote... When an exception occours in an XSP, it's stack trace
>will reflect the line number of where the exception happened AFTER the
>code has been translated from XML to JAVA... Do someone have any idea on
>how we can fix that?

Semi-random thoughts - modify Xalan (no I'm not volunteering for that!!!) to 
give the ability to build a map from pairs of Locators (org.xml.sax.Locator 
I think it is) representing fragments of the XSP to pairs of Locators in the 
.java source representing corresponding fragments in the generated source. 
Then use this map to translate back from a position in the .java source to a 
position in the XSP file if possible. Not sure what the most efficient data 
structure for a map from ranges to ranges is - maybe a binary search is the 
fastest way to look up in a list of ranges?

So either

A) it won't compile. Don't hide the name of the .java file from the user - 
let them read it to help debug. But still do a reverse-lookup and see if 
that line is part of the user's code.

B) run-time error. Either
i) it's in the users' code - do a reverse-lookup and show the line(s) from 
the XSP file instead. However, because bugs don't always show up in the line 
that they occur, may still need to show the name and line-numbers for the 
.java file as well.
ii) it's in the autogenerated code - (shrugs) - just output a normal stack 
trace
iii) can't tell whether it is in user's code or autogenerated code because 
they are on the same line! - solution - make sure the XSP engine never mixes 
them on the same line. However this depends on how accurate the line number 
table generated by the compiler is.

Would need to turn off JIT for B to work consistently, otherwise you get 
(xyz.java:Compiled Code) and you can't see where it stopped.

--
Robin

Open Source Java links galore! - 
http://dmoz.org/Computers/Programming/Languages/Java/Open_Source/

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com


Mime
View raw message