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 .
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
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
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
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
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
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
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
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
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
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
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,
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,
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
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
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]
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
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:
>>>
>>>
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
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:
>>>
>>>
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
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
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
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 ~
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
>> > without wrapping in another try-catch block. Exceptions
> 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
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))
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
2011/1/24 Laurent PETIT :
> Yes, you're right Shantanu.
>
> 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.
for the record, references:
apach
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
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
> 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
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
> 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
Yes, you're right Shantanu.
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.
Of course, with-open allowing to do several binding, the
try/swallow
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
> > finally block prevails over the exception raise
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 intended behavior or I a
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 are correct.
>
> Maybe this is subjective, but
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
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() throw - I would like it i
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=> (defprotocol Closeable (close [
(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@googlegroups.com
Note t
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
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
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
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 missing something?
>
> Is t
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 where the exceptio
47 matches
Mail list logo
