Hmm .. makes sense .. my thinking was its just a more flexible with-
open ... but from user's pov with-open-close is better...
Thanx
On Apr 29, 2:24 pm, Laurent PETIT wrote:
> Maybe juste the name ?
>
> wouldn't with-open-close be a better reminder of how the bindings are
> constructed ?
>
> 201
Maybe juste the name ?
wouldn't with-open-close be a better reminder of how the bindings are
constructed ?
2010/4/29 Alex Osborne :
> ka writes:
>
>> Above I wrote a macro with-open-flexi! ... which I'm planning to use
>> in my app's API . .. please let me know if there are any bugs /
>> gotchas
ka writes:
> Above I wrote a macro with-open-flexi! ... which I'm planning to use
> in my app's API . .. please let me know if there are any bugs /
> gotchas / improvements etc...
>
> I didn't get any responses, so does it means there is something so
> obviously wrong that you can't even begin wh
Hi ppl,
Above I wrote a macro with-open-flexi! ... which I'm planning to use
in my app's API . .. please let me know if there are any bugs /
gotchas / improvements etc...
I didn't get any responses, so does it means there is something so
obviously wrong that you can't even begin where to start :)
I wrote this, which seems to solve the problem being discussed:
http://gist.github.com/377278
Thoughts?
On Apr 23, 8:10 am, Armando Blancas wrote:
> > Is there any easy workaround which doesn't involve defing a global
> > conn.
>
> To do all in a single place you'll have to mimic the Java idi
> Is there any easy workaround which doesn't involve defing a global
> conn.
To do all in a single place you'll have to mimic the Java idiom.
(let [conn (atom nil)]
(try
(reset! conn (API/getConnection ...) ...
(catch ...)
(finally (if @conn (API/closeConnection @conn)
As it's
Hi all,
I've written my first macro: with-open-flexi!
(defmacro with-open-flexi!
" Just like with-open except it takes closing expression instead
of assuming it to be .close
Macro definition :
(with-open-flexi! [] body) expands to -
(do body)
(with-open-flexi! [obj1 init
The main thing about Perl6 in this case is that the catch/finally blocks are
inside the same scope as the try. But that's true in Clojure as well!
The difference is that Clojure's try is not itself a lexical binding scope;
you have to wrap one around it or within it via let. That's why I thought
Hi,
I don't know for sure, but it seems to me that perl 6 way of "writing"
exception handling is just a syntactic difference.
For an interesting shift in the possibilities of exception
handling/recovery, have a look at how Common Lisp does this with
conditions/restart :
http://www.gigamonkeys.com
Thanks all for replies.
Laurent, Alex you guys are right, the problem is only with aesthetics
of nesting / boilerplate. The nesting implementation semantically
expresses exactly what is required.
The with-cleanup macro seems really neat. Guess I'll learn macros
first and try to implement one.
On Wednesday 21 April 2010 15:06:40 ka wrote:
Hi!
> The macro solution looks good. But with 2 different APIs for 2
> connections, I would need to write 2 macros right?
No, not really. You could also make the symbols for the API class an
additional arg to the macro, like:
(defmacro with-api-c
ka writes:
> The whole code gets cluttered with all these try finally (and one
> catch) statements.
>
> (try
> (let [conn1 (API1/getConnection ..)]
> (try
> (let [conn2 (API2/getConnection ..)]
> (try
> ( ... Do something with conn1 conn2
2010/4/21 Mark J. Reed :
> On Wed, Apr 21, 2010 at 9:37 AM, Laurent PETIT
> wrote:
>>
>> Hi,
>>
>> Something I don't understand: if the call to (API/getConnection ...)
>> fails, there is nothing to close, right ?
>>
>> So for the problem of ensuring that any open connection is always
>> closed, th
On Wed, Apr 21, 2010 at 9:37 AM, Laurent PETIT wrote:
> Hi,
>
> Something I don't understand: if the call to (API/getConnection ...)
> fails, there is nothing to close, right ?
>
> So for the problem of ensuring that any open connection is always
> closed, the following pattern seems enough:
>
> (
Oh, also see the source code for with-open :
http://github.com/richhickey/clojure/blob/master/src/clj/clojure/core.clj#L2542
and also note that it allows you to declare bindings for opening
connections in sequence, and will take care of closing them in the
reverse order.
And to answer your questi
Hi,
Something I don't understand: if the call to (API/getConnection ...)
fails, there is nothing to close, right ?
So for the problem of ensuring that any open connection is always
closed, the following pattern seems enough:
(try
(let [conn (API/getConnection ..)]
XXX)
(finally (API/clo
On Wed, Apr 21, 2010 at 9:06 AM, ka wrote:
> Connection1 conn1 = null;
> Connection2 conn2 = null;
> try {
> conn1 = API1.getConnection ..;
> conn2 = API2.getConnection ..;
> ...
> }
You can't do that without using atoms or something, because you're assigning
to conn1 and conn2 twice. That'
Thanks for the reply Alex,
I thought of 2 try blocks, but seems over engineering doesn't it ? I
actually need to open 2 connections simultaneously, which would amount
to 3 nested try blocks. The whole code gets cluttered with all these
try finally (and one catch) statements.
(try
(let [con
ka writes:
> How can I do something like ...
>
> (try
> (let [conn (API/getConnection ..)]
> ())
> (catch ..)
> (finally (if conn (API/closeConnection conn
>
> Problem is that conn is unavailable in the finally context.
Why not just have two try blocks?
(try
(let [conn (API/g
19 matches
Mail list logo
