Re: Error info (was: A concern about object maint...)

[Hubert Rabago <hr...@gmail.com>]

(Moving to dev.)

I already started to take a look at this sometime ago.  (In fact, I
had to make sure I didn't check in changes I shouldn't while I was
working on those deprecations.)  The thing I ran into was, the result
I'd get wasn't always fully reliable.  If a forward of an action had a
problem, for instance, the line number I'd get would sometimes be the
one where the closing </action-mappings> tag was at.

It may be that the reliability of the line number we get would depend
on the SAX parser implementation in use.

I'll revisit the work I've already done one of these days and share my
observations.

Hubert

On 8/25/05, Joe Germuska <Jo...@germuska.com> wrote:
> One small thing we could do is go through everywhere there is a
> SAXException caught and add code to specifically catch a
> SAXParseException and use the several properties of that type to
> provide considerably more information than we do now.
> SAXParseException can tell you exactly the file name (system ID),
> line number and column where a syntax error occurred.  This could
> help a lot when debugging config file problems.
> 
> Similarly, there are other places where we throw through exceptions
> from underlying Commons libraries where we could strategically catch
> common exceptions which throw people (like a lookup exception for an
> <html:form> tag) and wrap them with contextual information based on
> years of experience.
> 
> It's hard, because when you've been doing this for a while, you can
> forget how you learned to decode some of the messages -- but I've
> been helping a few people get up to speed on Struts again recently
> and it has brought some of this to the foreground.
> 
> Joe
> 
> 
> 
> 
> At 9:22 AM -0500 8/25/05, Hubert Rabago wrote:
> >On 8/25/05, Kade Jeevan Kumar <je...@yahoo.com> wrote:
> >>
> >>  Whenever if i get any exception due to lack of co-ordination
> >>between my JSP form and ActionForm the error messages are not in a
> >>proper debuggable way.  Sometimes, if something goes wrong with the
> >>code it doesn't intimate me with proper error message, but common
> >>to all errors it gives me "bean-util exception"
> >>
> >>  If i want to fix the needed error in any of the JSP i need to go
> >>through struts-config.xml, tiles-def.xml, and then get the related
> >>JSP and then fix it out.
> >>
> >
> >There's a good chance that you'll encounter this same situation with
> >any framework that uses XML config files.  However, I agree (and I'm
> >not the only committer that does) that Struts can do a better job
> >providing information when something goes wrong (like, say, which
> >action forward it couldn't find).  I've made some tiny changes to
> >provide more information about an error condition in some situations,
> >but for the most part, I'd have to wait until somebody reports
> >something in particular before I'll know where to look.  I've been
> >looking at the situations reported in
> >http://issues.apache.org/bugzilla/show_bug.cgi?id=5739 and the issues
> >that were linked to it in one way or another.  (Now all I need is a
> >bit more free time.)  If you encounter something in particular that
> >you think Struts can do something about, file an enhancement request.
> >And if you could, some patches as well. :)  Actually, I really
> >wouldn't mind test cases I can use, or even a very small zip
> >containing files I can use to recreate the error (and help me verify
> >I've fixed it).  Sometimes the time consuming part is writing the
> >sample app to show me I'm done.
> >
> >Hubert
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >For additional commands, e-mail: user-help@struts.apache.org
> 
> 
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction"  -The Ex
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Error info (was: A concern about object maint...)

[Hubert Rabago <hr...@gmail.com>]

On 8/25/05, Hubert Rabago <hr...@gmail.com> wrote:
> I'll revisit the work I've already done one of these days and share my
> observations.

...but don't let me keep you from working on this!  If you have the
itch then by all means go ahead and take it on!

Hubert

> 
> On 8/25/05, Joe Germuska <Jo...@germuska.com> wrote:
> > One small thing we could do is go through everywhere there is a
> > SAXException caught and add code to specifically catch a
> > SAXParseException and use the several properties of that type to
> > provide considerably more information than we do now.
> > SAXParseException can tell you exactly the file name (system ID),
> > line number and column where a syntax error occurred.  This could
> > help a lot when debugging config file problems.
> >
> > Similarly, there are other places where we throw through exceptions
> > from underlying Commons libraries where we could strategically catch
> > common exceptions which throw people (like a lookup exception for an
> > <html:form> tag) and wrap them with contextual information based on
> > years of experience.
> >
> > It's hard, because when you've been doing this for a while, you can
> > forget how you learned to decode some of the messages -- but I've
> > been helping a few people get up to speed on Struts again recently
> > and it has brought some of this to the foreground.
> >
> > Joe

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Error info (was: A concern about object maint...)

[Hubert Rabago <hr...@gmail.com>]

On 8/25/05, Joe Germuska <Jo...@germuska.com> wrote:
> 
> I'm sure that's part of it -- but in my book, even just telling
> people which file has the problem would help a lot; at least, in my
> case, where we make a myriad of config files to make things easier to
> manage.  There are also probably just rules of XML such that the
> parser may legitimately consider the problem to be someplace other
> than where you do -- but it would still be better than nothing.
> 
> And the other thing, were we could add context and experience to
> "interpret" exceptions thrown from libraries instead of just passing
> them through or lightly wrapping them -- that could do a huge amount
> for usability.
>
> Joe

Agreed.  While I was disappointed in what I saw with my casual tests,
my thought then was to share my findings and see (1) where it could be
improved, and (2) which parts we deem valuable and helpful enough to
incorporate.

Hubert

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Error info (was: A concern about object maint...)

[Joe Germuska <Jo...@Germuska.com>]

At 3:20 PM -0500 8/25/05, Hubert Rabago wrote:
>(Moving to dev.)
>
>I already started to take a look at this sometime ago.  (In fact, I
>had to make sure I didn't check in changes I shouldn't while I was
>working on those deprecations.)  The thing I ran into was, the result
>I'd get wasn't always fully reliable.  If a forward of an action had a
>problem, for instance, the line number I'd get would sometimes be the
>one where the closing </action-mappings> tag was at.
>
>It may be that the reliability of the line number we get would depend
>on the SAX parser implementation in use.

I'm sure that's part of it -- but in my book, even just telling 
people which file has the problem would help a lot; at least, in my 
case, where we make a myriad of config files to make things easier to 
manage.  There are also probably just rules of XML such that the 
parser may legitimately consider the problem to be someplace other 
than where you do -- but it would still be better than nothing.

And the other thing, were we could add context and experience to 
"interpret" exceptions thrown from libraries instead of just passing 
them through or lightly wrapping them -- that could do a huge amount 
for usability.

Joe

-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com    
"Narrow minds are weapons made for mass destruction"  -The Ex

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org