You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Marcus Crafter <cr...@dresdnerbank.de> on 2000/10/17 14:18:43 UTC
[C2] xsp.xsl/devel code
Hi All,
Hope everything is going well!
Recently I've been porting some C1 XSP code over to C2 that uses a
several external classes we've written here for our web application.
One difference I've noticed is that the generated C2 XSP code does not
wrap up developer XSP logic code within a try/catch block like in C1.
In C1, the generated 'populateDocument()' method throws type
Exception; in effect allowing the developer handle exceptions they
want to and/or let others fall through to the error handling
capabilities of Cocoon.
C2 has no such support (yet?), requiring the developer to handle all
possible exceptions their code may throw (the C2 generated 'generate'
method can only throw SAXException).
My question is, was there a discussion/reason behind this decision ?
or was it just the way it happened ? :-)
I've attached a patch which adds a global try block to the C2
generated 'generate' method, which catches any developer caused
exceptions/errors.
It repackages them up as ProcessingException's (maybe another name
might be better ?) and re-throws them so that Cocoon's inbuilt
handling takes care of them. It catches Throwable so that Errors and
Exceptions are both handled.
Now, I can understand reasons not to do this, but I can also understand
reasons to do this, so maybe my patch is not appropriate ? Hence my
question above.
What is everyone else's thoughts ?
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: Open Software Associates GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&' Email : Marcus.Crafter@osa.de
&&&&. Business Hours : +49 69 9757 200
&&&&&&&: After Hours : +49 69 49086750
Re: [C2] xsp.xsl/devel code
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 17:49 +0200 17/10/00, Stefano Mazzocchi wrote:
>
>> I've attached a patch which adds a global try block to the C2
>> generated 'generate' method, which catches any developer caused
>> exceptions/errors.
>
>Hmmm, it might increase your lazyness which is not good, but on the
>other hand it could simplify some coding and adding visibility to the
>code which is good.
>
>> What is everyone else's thoughts ?
>
>I'm +0 on this..., I would love more comments on this before stating a
>pending opinion.
I do not know whether my goal of writing TagLibs that are X-compatible with
C1 & C2 is worthwhile or not :)
But the closer the two running environments are to each other, the easier
it will be to do this.
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
Re: [C2] xsp.xsl/devel code
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
From: "Stefano Mazzocchi" <st...@apache.org>
> Marcus Crafter wrote:
> >
> > On Tue, 17 Oct 2000, Stefano Mazzocchi wrote:
> >
> > > Marcus Crafter wrote:
> > > >
> > > > Now, I can understand reasons not to do this, but I can also
understand
> > > > reasons to do this, so maybe my patch is not appropriate ?
Hence my
> > > > question above.
> > >
> > > Hmmm, it might increase your lazyness which is not good, but on the
> > > other hand it could simplify some coding and adding visibility to the
> > > code which is good.
> >
> > I agree with both of your points :-)
> >
> > I tend to see the benefits of quick prototyping, clean clear
code with
> > well placed exception handlers out of good coding rather than
need,
> > more than prevention of sloppy code (no sloppy coders use C2
:-) )
> >
> > I could also see situations where fatal errors in XSP code mean
that
> > an application is out of action - where the application wide
error
> > handler is better suited to handle the error with it's own
> > stylesheets.
> >
> > But perhaps more expercienced developers out there might like to
> > comment.
> >
> > Maybe making it configurable might also be an option ? Kind of
> > like 'use strict;' in perl.
>
> Well, I think that if not caught, XSP exceptions should trigger the
> error page creation which is specified in the sitemap... this requires
> try/catch encapsulation.... but that means you can't catch your own
> stuff
Hmmm... what do you mean you can't catch your own stuff?
If the error has to be handled in the xsp you won't trigger the sitemap
exception
try-catch.
If it has to be notified to the user, you can create your exception that
implements
the interface Notificable and the error generator formats to xml the extra
info;
then you can do what you want with that.
Am I making sense? :-)
>.... hmmmm, Ricardo, any thoughs on this?
nicola_ken
Re: [C2] xsp.xsl/devel code
Posted by Stefano Mazzocchi <st...@apache.org>.
Marcus Crafter wrote:
>
> On Tue, 17 Oct 2000, Stefano Mazzocchi wrote:
>
> > Marcus Crafter wrote:
> > >
> > > Now, I can understand reasons not to do this, but I can also understand
> > > reasons to do this, so maybe my patch is not appropriate ? Hence my
> > > question above.
> >
> > Hmmm, it might increase your lazyness which is not good, but on the
> > other hand it could simplify some coding and adding visibility to the
> > code which is good.
>
> I agree with both of your points :-)
>
> I tend to see the benefits of quick prototyping, clean clear code with
> well placed exception handlers out of good coding rather than need,
> more than prevention of sloppy code (no sloppy coders use C2 :-) )
>
> I could also see situations where fatal errors in XSP code mean that
> an application is out of action - where the application wide error
> handler is better suited to handle the error with it's own
> stylesheets.
>
> But perhaps more expercienced developers out there might like to
> comment.
>
> Maybe making it configurable might also be an option ? Kind of
> like 'use strict;' in perl.
Well, I think that if not caught, XSP exceptions should trigger the
error page creation which is specified in the sitemap... this requires
try/catch encapsulation.... but that means you can't catch your own
stuff.... hmmmm, Ricardo, any thoughs on this?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [C2] xsp.xsl/devel code
Posted by Marcus Crafter <cr...@dresdnerbank.de>.
On Tue, 17 Oct 2000, Stefano Mazzocchi wrote:
> Marcus Crafter wrote:
> >
> > Now, I can understand reasons not to do this, but I can also understand
> > reasons to do this, so maybe my patch is not appropriate ? Hence my
> > question above.
>
> Hmmm, it might increase your lazyness which is not good, but on the
> other hand it could simplify some coding and adding visibility to the
> code which is good.
I agree with both of your points :-)
I tend to see the benefits of quick prototyping, clean clear code with
well placed exception handlers out of good coding rather than need,
more than prevention of sloppy code (no sloppy coders use C2 :-) )
I could also see situations where fatal errors in XSP code mean that
an application is out of action - where the application wide error
handler is better suited to handle the error with it's own
stylesheets.
But perhaps more expercienced developers out there might like to
comment.
Maybe making it configurable might also be an option ? Kind of
like 'use strict;' in perl.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: Open Software Associates GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&' Email : Marcus.Crafter@osa.de
&&&&. Business Hours : +49 69 9757 200
&&&&&&&: After Hours : +49 69 49086750
Re: [C2] xsp.xsl/devel code
Posted by Stefano Mazzocchi <st...@apache.org>.
Marcus Crafter wrote:
>
> Hi All,
>
> Hope everything is going well!
>
> Recently I've been porting some C1 XSP code over to C2 that uses a
> several external classes we've written here for our web application.
>
> One difference I've noticed is that the generated C2 XSP code does not
> wrap up developer XSP logic code within a try/catch block like in C1.
>
> In C1, the generated 'populateDocument()' method throws type
> Exception; in effect allowing the developer handle exceptions they
> want to and/or let others fall through to the error handling
> capabilities of Cocoon.
>
> C2 has no such support (yet?), requiring the developer to handle all
> possible exceptions their code may throw (the C2 generated 'generate'
> method can only throw SAXException).
>
> My question is, was there a discussion/reason behind this decision ?
> or was it just the way it happened ? :-)
I guess it's just the way it happened, but I'd welcome some more
reasoning about this.
> I've attached a patch which adds a global try block to the C2
> generated 'generate' method, which catches any developer caused
> exceptions/errors.
>
> It repackages them up as ProcessingException's (maybe another name
> might be better ?) and re-throws them so that Cocoon's inbuilt
> handling takes care of them. It catches Throwable so that Errors and
> Exceptions are both handled.
>
> Now, I can understand reasons not to do this, but I can also understand
> reasons to do this, so maybe my patch is not appropriate ? Hence my
> question above.
Hmmm, it might increase your lazyness which is not good, but on the
other hand it could simplify some coding and adding visibility to the
code which is good.
> What is everyone else's thoughts ?
I'm +0 on this..., I would love more comments on this before stating a
pending opinion.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------