- close with fileutils.close instead of manually
Kev
Index: BaseFilterReader.java
===
RCS file:
/home/cvspublic/ant/src/main/org/apache/tools/ant/filters/BaseFilterReader.java,v
retrieving revision 1.18
diff -u -r1.18
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
gt; 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 death" for close, that there is i
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 &q
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'
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 propose that instead of this "silent death" fo
Matt Benson wrote:
PING...
--- Matt Benson <[EMAIL PROTECTED]> wrote:
[SNIP]
In
talking about whether caught Exceptions should at
least be logged, Jesse mentioned "disk full" as an
example. We actually have a bugrep (32676) about
full
directories, and I found a blog today on which a
German fell
eWriter to
> use
> an instance of (hypothetically) oata.util.FOS and
> force the Exception on full disk.
Any more opinions on this? We could add this to
LazyFileOutputStream and check whether performance
degrades as Jesse has mentioned he fears.
> But it won't help
> anything unless we log
Matt Benson wrote:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4338871
Normal application code should not have to go around making special
low-level calls like this.
Now, Jesse, that's all well and good to say, but I find it hard to
believe you have spent several years working on NetBeans wi
--- Jesse Glick <[EMAIL PROTECTED]> wrote:
> Matt Benson wrote:
> > [...] the Exception won't be thrown unless you
> explicitly sync() the
> > FileDescriptor; otherwise the write will take
> place in cache and the
> > result on disk later will be a zero-byte file.
> [...]
>
> So close() is not e
Matt Benson wrote:
[...] the Exception won't be thrown unless you explicitly sync() the
FileDescriptor; otherwise the write will take place in cache and the
result on disk later will be a zero-byte file. [...]
So close() is not enough, you have to sync()? If true this sounds like a
bug in the JRE
--- Jesse Glick <[EMAIL PROTECTED]> wrote:
> Matt Benson wrote:
> > [...] In talking about whether caught Exceptions
> should at least be
> > logged, Jesse mentioned "disk full" as an example.
> [...] I found a
> > blog today [with] a workaround to detect this
> condition when writing
> > with a F
Matt Benson wrote:
[...] In talking about whether caught Exceptions should at least be
logged, Jesse mentioned "disk full" as an example. [...] I found a
blog today [with] a workaround to detect this condition when writing
with a FOS, using the sync() method of the descriptor available from
the str
been thinking about the logging within Ant for a while now, and
whilst people are suggesting solutions, here's my take.
- Log4j works perfectly well for logging, so long as the developer puts
the call in at the appropriate place.
- FileUtils.close() seems to swallow problems that occur wh
t the logging within Ant for a while now, and
whilst people are suggesting solutions, here's my take.
- Log4j works perfectly well for logging, so long as the developer puts
the call in at the appropriate place.
- FileUtils.close() seems to swallow problems that occur when closing files
- For
nstance of (hypothetically) oata.util.FOS and
force the Exception on full disk. But it won't help
anything unless we log Exceptions from
FileUtils.close(*)... So I am for at least writing to
System.err .
Another thought: We could create an AntThread class
to tie a Thread to a Project. Most places
(I'm just catching up on 3 weeks worth of mail, sorry for joining in late)
>> So what exactly *is* the intention of this method? [...]
We wrote it because we were repeating the same code throughout exception
handling logic: closing files and swallowing exceptions.
try {
file=myfile.open();
...
Kev Jackson wrote:
So what exactly *is* the intention of this method? [...]
1.
My intention was only to uniform the codebase around the helper methods
that were presumably created for this sort of task.
Yes, I was really addressing other committers generally, sorry for the
confusion.
I should ad
n tries to close() stream/reader - and this
can be replaced by one line FileUtils.close(), then surely this is more
readable?
OutputStream os = null;
try {
os = new FileOutputStream(...);
printStuffToStream(os);
} catch (IOException e) {
throw new BuildException(e);
Kev Jackson wrote:
As an aside, I went through the entire codebase last night and replaced
every
try {
somthing.close()
} catch (IOException e) {
//swallow exception
}
with FileUtils.close()
So what exactly *is* the intention of this method? IMHO, if an
IOException was thrown when some
22 matches
Mail list logo
