On Jan 24, 3:05 pm, Laurent PETIT <laurent.pe...@gmail.com> wrote: > 2011/1/24 David Powell <djpow...@djpowell.net>: > > > > >> apache commons io and spring framework, to name 2 things I know for > >> sure, are doing what you say: they swallow any exception that could be > >> thrown within the finally block, for the reasons you mention. > > > True, but if the body doesn't throw an exception, but the close does, > > I wouldn't want the close exception swallowed. > > > Consider if you are writing to a socket via a buffered stream - > > nothing may be written until the buffer is flushed when you call > > close(). This is of course why close() throws Exception in the first > > place. > > Could you please expand with an example, I'm not sure I'm following you. > Especially, if my memories don't cheat on me, calling close() ensures > Bufferd[Writer|OutputStream]s are flushed, for example.
Yes, but if that flush causes an IO error, you don't want it silently swallowed. > And also, what if the user code inside with-open throws an exception, > but the close() calls also throw an exception. > You cannot see the exception raised by close() anymore => you cannot > expect consistency with your solution ? You can't really do anything about this. If two exceptions are thrown, one of them will be hidden. I think it makes a lot of sense to throw the "first exception", but still try to close any streams if possible. Usually if a .close fails after a read/write fails, there's not much you can do - it's sad, but not The read/write exception is much more important and is what should percolate up the stack. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
