> 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
Hi,
As part of a bug report on 's keepgoing functionality,
we started talking about why ANT was not catching RuntimeExceptions
(and maybe Errors) from the tasks and converting them to BuildExceptions
with proper location information.
We never did something about it besides fixing the specific
p
13 matches
Mail list logo
