> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> On Tue, 11 May 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
>
> > The notion is not to swallow / ignore them (unless the build script
> > author wants to) but to wrap them in a build exception to possibly
> > provide some information as to
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> On Wed, 05 May 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
>
> > I see verify errors sometimes with beanshell and groovy scripts.
>
> Because you are reloading classes which is a problem in its
> own. I think you'd better find a way to av
On Tue, 11 May 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
> The notion is not to swallow / ignore them (unless the build script
> author wants to) but to wrap them in a build exception to possibly
> provide some information as to where the error happened - the line
> number of the build script
Stefan Bodewig wrote:
On Wed, 05 May 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
I see verify errors sometimes with beanshell and groovy
scripts.
Because you are reloading classes which is a problem in its own. I
think you'd better find a way to avoid these VerifyErrors instead of
swallo
On Wed, 05 May 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
> I see verify errors sometimes with beanshell and groovy
> scripts.
Because you are reloading classes which is a problem in its own. I
think you'd better find a way to avoid these VerifyErrors instead of
swallowing/ignoring them. 8-)
I see verify errors sometimes with beanshell and groovy
scripts.
Peter
Stefan Bodewig wrote:
On Wed, 05 May 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
There are a lot of "errors" that should be converted
to buildexceptions.
examples are "NoClassDefFoundError", "VerifyError" etc
IMHO the
On Wed, 05 May 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
> There are a lot of "errors" that should be converted
> to buildexceptions.
>
> examples are "NoClassDefFoundError", "VerifyError" etc
IMHO the build is seriously busted if we run into VerifyErrors.
How would you know that an error i
Errors.
In any case, is there concensus to do at least the RuntimeExceptions.
Jose Alberto
-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
Sent: 05 May 2004 07:34
To: [EMAIL PROTECTED]
Subject: Re: Trapping RuntimeExceptions form Tasks
On 04 May 2004, Erik Meade <[
May 2004 07:34
> To: [EMAIL PROTECTED]
> Subject: Re: Trapping RuntimeExceptions form Tasks
>
>
> On 04 May 2004, Erik Meade <[EMAIL PROTECTED]> wrote:
>
> > Why don't you feel comfortable catching Errors?
>
> Since Errors should only be thrown in unre
On 04 May 2004, Erik Meade <[EMAIL PROTECTED]> wrote:
> Why don't you feel comfortable catching Errors?
Since Errors should only be thrown in unrecoverable situations (that's
the theory, I know).
I don't think that Ant should continue after an OutOfMemoryError for
example There are others and w
On Tue, 2004-05-04 at 07:40, Stefan Bodewig wrote:
> On Tue, 4 May 2004, Jose Alberto Fernandez <[EMAIL PROTECTED]>
> wrote:
>
> > I think part of the difficulty was whether to catch only
> > RuntimeExceptions or all Throwables (except for some very few).
>
> I wouldn't feel comfortable with catch
On Tue, 4 May 2004, Jose Alberto Fernandez <[EMAIL PROTECTED]>
wrote:
> Is there any interest on this issue?
Not too much, it seems 8-)
> Shall we track it in bugzilla?
I prefer to have development discussions on this list. YMMV.
> I think part of the difficulty was whether to catch only
> Ru
12 matches
Mail list logo