On Wed, 22 Jun 2005, Jesse Glick <[EMAIL PROTECTED]> wrote:
> That's one option. Another is to just assume the worst and throw the
> IOException from whatever.close()
One of the problems in addition to changing a whole lot of method
signatures is that we want to close files even in the error case
IOException is a checked exception, so it has to be specified everywhene.
BuildException would be a better alternative.
- Alexey.
On 6/22/05, Jesse Glick <[EMAIL PROTECTED]> wrote:
>
> Kev Jackson wrote:
> > This came up before, but I forgot what the consensus was
>
> Not sure there was a cons
Kev Jackson wrote:
This came up before, but I forgot what the consensus was
Not sure there was a consensus (or that anyone cared enough).
Whenever FileUtils.close() is used, any resulting exceptions are
swallowed and no logging is performed. I'd like to propose that
instead of this "silent d
Kev Jackson wrote:
Alexey N. Solofnenko wrote:
Maybe just ioex.printStackTrace()?
I thought it would be better to log to the specific calling task
(although getting the error message from the exception makes perfect
sense). I seem to recall a complaint about close silent behaviour with
a
Alexey N. Solofnenko wrote:
Maybe just ioex.printStackTrace()?
I thought it would be better to log to the specific calling task
(although getting the error message from the exception makes perfect
sense). I seem to recall a complaint about close silent behaviour with
a full filesystem and
Maybe just ioex.printStackTrace()?
- Alexey.
Kev Jackson wrote:
This came up before, but I forgot what the consensus was (been a while
since I've had time to play with Ant). Whenever FileUtils.close() is
used, any resulting exceptions are swallowed and no logging is
performed. I'd like to p
