Re: Calling .close() on resources -- with-open macro

On Jan 25, 7:32 pm, Meikel Brandmeyer wrote: > Hi, > > Disclaimer: I have no clue, what I'm talking about. Just making up > contrived examples, which probably never happen in reality. > > On 25 Jan., 15:13, Ken Wesson wrote: > > > Remember, we're no longer using a "finally" clause, so for the .

Re: Calling .close() on resources -- with-open macro

Hi, Disclaimer: I have no clue, what I'm talking about. Just making up contrived examples, which probably never happen in reality. On 25 Jan., 15:13, Ken Wesson wrote: > Remember, we're no longer using a "finally" clause, so for the .close > to be exception-safe *everything* must be caught. But

Re: Calling .close() on resources -- with-open macro

On Tue, Jan 25, 2011 at 1:03 AM, Shantanu Kumar wrote: > The changed code should catch 'Exception', not 'Throwable' because the > latter is a common ancestor of both 'Exception' and 'Error'. An > 'Error' must not be swallowed at any point in the system, unless you > are writing an app server or a

Re: Calling .close() on resources -- with-open macro

On Tue, Jan 25, 2011 at 1:04 PM, Shantanu Kumar wrote: I can't see the value in catching Throwable and then re-throwing it; > idiomatically Throwable is rarely caught. Looking at code example, the > following two snippets below are just the same: > > (try > (.close resource) > (catch Throwable t

Re: Calling .close() on resources -- with-open macro

On Jan 25, 4:22 pm, David Powell wrote: > On 25 Jan 2011 06:04, "Shantanu Kumar" wrote: > > > > > The changed code should catch 'Exception', not 'Throwable' because the > > latter is a common ancestor of both 'Exception' and 'Error'. An > > 'Error' must not be swallowed at any point in the syst

Re: Calling .close() on resources -- with-open macro

On 25 Jan 2011 06:04, "Shantanu Kumar" wrote: > > The changed code should catch 'Exception', not 'Throwable' because the > latter is a common ancestor of both 'Exception' and 'Error'. An > 'Error' must not be swallowed at any point in the system, unless you > are writing an app server or a JVM imp

Re: Calling .close() on resources -- with-open macro

On Jan 25, 2:30 pm, Laurent PETIT wrote: > 2011/1/25 Shantanu Kumar : > > > The changed code should catch 'Exception', not 'Throwable' because the > > latter is a common ancestor of both 'Exception' and 'Error'. An > > 'Error' must not be swallowed at any point in the system, unless you > > are

Re: Calling .close() on resources -- with-open macro

2011/1/25 Shantanu Kumar : > The changed code should catch 'Exception', not 'Throwable' because the > latter is a common ancestor of both 'Exception' and 'Error'. An > 'Error' must not be swallowed at any point in the system, unless you > are writing an app server or a JVM implementation. ;-) True

Re: Calling .close() on resources -- with-open macro

2011/1/25 Ken Wesson : > Huh. We came up with almost the same final version. I guess I took 13 > minutes longer because I tested mine And also because I was in a hurry to go to bed ! :) >-- yours still has the missing #. > :) This was intentional, I had to let something for you to bite ;) -- Y

Re: Calling .close() on resources -- with-open macro

2011/1/25 Meikel Brandmeyer : > Hi, > > On 25 Jan., 01:57, Laurent PETIT wrote: > >> (try (. ~(bindings 0) close) (catch Throwable _)) > > New code should use (.close foo) instead of (. foo close), IIRC. Sure, but it's an enhancement over existing code, so I've followed the convention (and I was

Re: Calling .close() on resources -- with-open macro

Hi, On 25 Jan., 01:57, Laurent PETIT wrote: > (try (. ~(bindings 0) close) (catch Throwable _)) New code should use (.close foo) instead of (. foo close), IIRC. Sincerely Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this grou

Re: Calling .close() on resources -- with-open macro

Hi, On 25 Jan., 01:33, Ken Wesson wrote: > It looks a little quirky in macroexpand output and seems slightly ugly > but it works and probably isn't even inefficient at runtime, as the > close symbol presumably has a name slot that takes up four bytes > whether it's nil or a pointer to a string,

Re: Calling .close() on resources -- with-open macro

The changed code should catch 'Exception', not 'Throwable' because the latter is a common ancestor of both 'Exception' and 'Error'. An 'Error' must not be swallowed at any point in the system, unless you are writing an app server or a JVM implementation. ;-) Regards, Shantanu On Jan 25, 6:11 am,

Re: Calling .close() on resources -- with-open macro

Huh. We came up with almost the same final version. I guess I took 13 minutes longer because I tested mine -- yours still has the missing #. :) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.c

Re: Calling .close() on resources -- with-open macro

On Mon, Jan 24, 2011 at 7:43 PM, Laurent PETIT wrote: > 2011/1/25 Ken Wesson : >> Ah, I guess it may be a bit cleaner to just eschew "finally" >> altogether and close in the try and in the catch. The one thing that's >> a bit icky about that is that if the body close throws, the catch >> clause tr

Re: Calling .close() on resources -- with-open macro

There it is, corrected: (in-ns 'clojure.core) (defmacro with-open "bindings => [name init ...] Evaluates body in a try expression with names bound to the values of the inits, and a finally clause that calls (.close name) on each name in reverse order." {:added "1.0"} [bindings & body]

Re: Calling .close() on resources -- with-open macro

of course I missed something :-( 2011/1/25 Laurent PETIT : > 2011/1/25 Ken Wesson : >> On Mon, Jan 24, 2011 at 7:32 PM, Laurent PETIT >> wrote: >>> 2011/1/25 Ken Wesson : Are we generally agreed that we want to preserve the body exception, if any, else the close exception, if any, else

Re: Calling .close() on resources -- with-open macro

2011/1/25 Ken Wesson : > On Mon, Jan 24, 2011 at 7:32 PM, Laurent PETIT > wrote: >> 2011/1/25 Ken Wesson : >>> Are we generally agreed that we want to preserve the body exception, >>> if any, else the close exception, if any, else the body return value? >>> >>> Then, without further ado: >>> >>>

Re: Calling .close() on resources -- with-open macro

On Mon, Jan 24, 2011 at 7:40 PM, Alan wrote: > Thanks, Ken. Much more productive than all this philosophy about what > "makes sense" the rest of us are discussing; I'd vote for this patch > if you put it in JIRA. No patch; sorry; don't have a CA. Laurent improved on it somewhat anyway. You're we

Re: Calling .close() on resources -- with-open macro

2011/1/25 Ken Wesson : > On Mon, Jan 24, 2011 at 7:32 PM, Laurent PETIT > wrote: >> 2011/1/25 Ken Wesson : >>> Are we generally agreed that we want to preserve the body exception, >>> if any, else the close exception, if any, else the body return value? >>> >>> Then, without further ado: >>> >>>

Re: Calling .close() on resources -- with-open macro

Thanks, Ken. Much more productive than all this philosophy about what "makes sense" the rest of us are discussing; I'd vote for this patch if you put it in JIRA. On Jan 24, 3:59 pm, Ken Wesson wrote: > Are we generally agreed that we want to preserve the body exception, > if any, else the close e

Re: Calling .close() on resources -- with-open macro

On Mon, Jan 24, 2011 at 7:32 PM, Laurent PETIT wrote: > 2011/1/25 Ken Wesson : >> Are we generally agreed that we want to preserve the body exception, >> if any, else the close exception, if any, else the body return value? >> >> Then, without further ado: >> >> (defmacro with-open2 [binding-exprs

Re: Calling .close() on resources -- with-open macro

On Mon, Jan 24, 2011 at 7:26 PM, Aaron Cohen wrote: > The inner exception to me should clearly be caught and not rethrown. > So I would really expect to see two printouts when this is run, once > for doit and once for close. Neither would I. I think you've misunderstood something, though. > Why

Re: Calling .close() on resources -- with-open macro

2011/1/25 Ken Wesson : > Are we generally agreed that we want to preserve the body exception, > if any, else the close exception, if any, else the body return value? > > Then, without further ado: > > (defmacro with-open2 [binding-exprs & body] >  (if (> (count binding-exprs) 2) >    `(with-open2 ~

Re: Calling .close() on resources -- with-open macro

On Mon, Jan 24, 2011 at 4:54 PM, Shantanu Kumar wrote: > > > On Jan 25, 2:47 am, Aaron Cohen wrote: >> On Mon, Jan 24, 2011 at 2:27 PM, Shantanu Kumar >> >> wrote: >> > I noticed that in 'with-open' macro the .close() method is called >> >

Re: Calling .close() on resources -- with-open macro

hat I tend to do in Java else things get too verbose, but it would be possible for the with-open macro to take the pain out of doing things slightly more robustly. 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

Re: Calling .close() on resources -- with-open macro

Are we generally agreed that we want to preserve the body exception, if any, else the close exception, if any, else the body return value? Then, without further ado: (defmacro with-open2 [binding-exprs & body] (if (> (count binding-exprs) 2) `(with-open2 ~(vec (take 2 binding-exprs))

Re: Calling .close() on resources -- with-open macro

2011/1/25 Alan : > On Jan 24, 3:05 pm, Laurent PETIT wrote: >> 2011/1/24 David Powell : >> >> >> >> >> 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 rea

Re: Calling .close() on resources -- with-open macro

ers, > > -- > Laurent > > 2011/1/24 Shantanu Kumar : >> >> >> On Jan 25, 2:07 am, dysinger wrote: >>> (try (with-open [x y] ... ) >>>      (catch Exception))  ;; <- catches any exception from with-open macro >>> >>> I don'

Re: Calling .close() on resources -- with-open macro

On Jan 24, 3:05 pm, Laurent PETIT wrote: > 2011/1/24 David Powell : > > > > >> 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. > > > Tr

Re: Calling .close() on resources -- with-open macro

2011/1/25 Laurent PETIT : > 2011/1/24 David Powell : >> >>> 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 do

Re: Calling .close() on resources -- with-open macro

hat I tend to do in Java else things get too verbose, but it would be possible for the with-open macro to take the pain out of doing things slightly more robustly. 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

Re: Calling .close() on resources -- with-open macro

2011/1/24 David Powell : > >> 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

Re: Calling .close() on resources -- with-open macro

> 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

Re: Calling .close() on resources -- with-open macro

e try/swallow-catch would have to be repeated for each nesting, IMHO. Cheers, -- Laurent 2011/1/24 Shantanu Kumar : > > > On Jan 25, 2:07 am, dysinger wrote: >> (try (with-open [x y] ... ) >>      (catch Exception))  ;; <- catches any exception from with-open macro >&g

Re: Calling .close() on resources -- with-open macro

On Jan 25, 2:47 am, Aaron Cohen wrote: > On Mon, Jan 24, 2011 at 2:27 PM, Shantanu Kumar > > wrote: > > I noticed that in 'with-open' macro the .close() method is called > > without wrapping in another try-catch block. Exceptions raised in the > > fina

Re: Calling .close() on resources -- with-open macro

On Mon, Jan 24, 2011 at 2:27 PM, Shantanu Kumar wrote: > I noticed that in 'with-open' macro the .close() method is called > without wrapping in another try-catch block. Exceptions raised in the > finally block prevails over the exception raised in the try block. Is > this

Re: Calling .close() on resources -- with-open macro

On Mon, 24 Jan 2011 13:30:49 -0800 (PST) Shantanu Kumar wrote: > > > On Jan 25, 2:07 am, dysinger wrote: > > (try (with-open [x y] ... ) > >      (catch Exception))  ;; <- catches any exception from with-open > > macro > > > > I don't think you

Re: Calling .close() on resources -- with-open macro

Yes. you are correct and I agree that you would lose the original exception or return type. I was just saying you could catch the exception of the IO close if needed. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email

Re: Calling .close() on resources -- with-open macro

On Jan 25, 2:07 am, dysinger wrote: > (try (with-open [x y] ... ) >      (catch Exception))  ;; <- catches any exception from with-open macro > > I don't think you are correct. Maybe this is subjective, but I am rarely interested in knowing what exception does .close() thr

Re: Calling .close() on resources -- with-open macro

On Mon, Jan 24, 2011 at 4:07 PM, dysinger wrote: > > (try (with-open [x y] ... ) >      (catch Exception))  ;; <- catches any exception from with-open macro > > I don't think you are correct. He is. Close exceptions lose any other exception or return value: user=> (de

Re: Calling .close() on resources -- with-open macro

(try (with-open [x y] ... ) (catch Exception)) ;; <- catches any exception from with-open macro I don't think you are correct. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@goo

Re: Calling .close() on resources -- with-open macro

On Jan 25, 1:26 am, dysinger wrote: > Just wrap it if you are paranoid about exception on close > > (try (with-open [x y] >        (throw (Exception. "lololol"))) >      (catch Exception e (println (.getMessage e     The problem is that exception thrown by .close() overshadows any return va

Re: Calling .close() on resources -- with-open macro

Just wrap it if you are paranoid about exception on close (try (with-open [x y] (throw (Exception. "lololol"))) (catch Exception e (println (.getMessage e -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send

Re: Calling .close() on resources -- with-open macro

On Jan 24, 2011, at 1:54 PM, Laurent PETIT wrote: > That's interesting. Indeed, it seems to me that the .close() call > should be wrapped by a try / catch with an empty catch. Why would client code want an exception thrown by .close() to get swallowed? Is that not unexpected behavior in most cas

Re: Calling .close() on resources -- with-open macro

2011/1/24 Shantanu Kumar : > I noticed that in 'with-open' macro the .close() method is called > without wrapping in another try-catch block. Exceptions raised in the > finally block prevails over the exception raised in the try block. Is > this intended behavior or I am mis

Calling .close() on resources -- with-open macro

I noticed that in 'with-open' macro the .close() method is called without wrapping in another try-catch block. Exceptions raised in the finally block prevails over the exception raised in the try block. Is this intended behavior or I am missing something? Is there an alternative

Re: with-open macro

Andrew, that code caused me to have headache some minutes ago :). On Tue, May 12, 2009 at 6:43 PM, Emeka wrote: > Why? > > > On Tue, May 12, 2009 at 5:37 PM, Andrew Wagner wrote: > >> Wow. Ok, yeah, I'm glad he didn't put that version in the article :) >> >> >> On Tue, May 12, 2009 at 1:17 PM, S

Re: with-open macro

Oh, it's just significantly harder to read if you don't know clojure, that's all. On Tue, May 12, 2009 at 2:43 PM, Emeka wrote: > Why? > > > On Tue, May 12, 2009 at 5:37 PM, Andrew Wagner wrote: > >> Wow. Ok, yeah, I'm glad he didn't put that version in the article :) >> >> >> On Tue, May 12, 20

Re: with-open macro

Why? On Tue, May 12, 2009 at 5:37 PM, Andrew Wagner wrote: > Wow. Ok, yeah, I'm glad he didn't put that version in the article :) > > > On Tue, May 12, 2009 at 1:17 PM, Stephen C. Gilardi wrote: > >> >> On May 12, 2009, at 12:30 PM, Andrew Wagner wrote: >> >>> It seems like this idiom would be ea

Re: with-open macro

Wow. Ok, yeah, I'm glad he didn't put that version in the article :) On Tue, May 12, 2009 at 1:17 PM, Stephen C. Gilardi wrote: > > On May 12, 2009, at 12:30 PM, Andrew Wagner wrote: > >> It seems like this idiom would be easy to implement in this macro. Or am I >> missing something? >> > > The c

Re: with-open macro

On May 12, 2009, at 12:30 PM, Andrew Wagner wrote: It seems like this idiom would be easy to implement in this macro. Or am I missing something? The current implementation of clojure.core/with-open works with multiple bindings the way you're advocating. The one in the article makes for an

Re: with-open macro

Hi, Am 12.05.2009 um 18:56 schrieb Andrew Wagner: Right, my question is why I can't do this: (with-open [rdr (reader file) writer (get-writer) foo (get-a-foo)] ...) In fact you can do and Clojure will close the Closables in reverse order. The information you found is outdated. Sincerely Mei

Re: with-open macro

The reason is because Clojure obeys arity to the letter and spirit. So if you want to tweak the code to do that, just build you only macro to accept that arity. Emeka On Tue, May 12, 2009 at 4:56 PM, Andrew Wagner wrote: > Right, my question is why I can't do this:(with-open [rdr (reader file) >

Re: with-open macro

Right, my question is why I can't do this:(with-open [rdr (reader file) writer (get-writer) foo (get-a-foo)] ...) On Tue, May 12, 2009 at 12:51 PM, Emeka wrote: > (with-open [rdr (reader file)] > ...) > So the vector you referred to is for binding and in imperative that means > assignin

Re: with-open macro

(with-open [rdr (reader file)] ...) So the vector you referred to is for binding and in imperative that means assigning rdr to function (reader file). So now it is pretty obvious that what you need is the variable, rdr, (in side the scope) and that's why clojure takes only the first element

with-open macro

I just saw this on the JavaWorld article (great article by the way: http://www.javaworld.com/javaworld/jw-05-2009/jw-05-clojure.html ) (defmacro with-open [bindings & body] `(let bindings (try @body (finally (