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. 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 ? > > A solution might be to change the macro to create a with-local-var var > at the top, and to add catch blocks with each finally that first > preserve the exception in the var. At the end of the block if any > exception was stored in the var, it should be rethrown, otherwise the > expression value should be returned. > > -- > Dave > > -- 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
