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. One more interesting perspective to exceptional handling is the way Perl 6 is doing it - http://feather.perl6.nl/syn/S04.html#Exception_handlers See this - { my $s = ''; die 3; CATCH { when 1 {$s ~= 'a';} when 2 {$s ~= 'b';} when 3 {$s ~= 'c';} when 4 {$s ~= 'd';} default {$s ~= 'z';} } is $s, 'c', 'Caught number'; }; Thanks! On Apr 21, 7:05 pm, Alex Osborne <a...@meshy.org> wrote: > ka <sancha...@gmail.com> 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 ............) > > (finally > > (API2/closeConnection conn2)))) > > (finally > > (API1/closeConnection conn1)))) > > (catch Exception ex (.printStackTrace ex))) > > I guess the main difference in this compared to your java example is the > levels of nesting. This may look messy but it's semantically exactly > what you're trying to express. > > > The macro solution looks good. But with 2 different APIs for 2 > > connections, I would need to write 2 macros right? > > > (defmacro with-api1-connection [conn-sym arg1 arg2 & body] > > `(let [~conn-sym (API1/getConnection ~arg1 ~arg2)] > > (try > > ~...@body > > (finally (API1/closeConnection ~conn-sym))))) > > > (defmacro with-api2-connection [conn-sym arg1 arg2 arg3 & body] > > `(let [~conn-sym (API2/getConnection ~arg1 ~arg2 ~arg3)] > > (try > > ~...@body > > (finally (API2/closeConnection ~conn-sym))))) > > You could make things more general: > > (with-cleanup [conn1 (API1/getConnection ...) API1/closeConnection > conn2 (API2/openConnection ...) #(.disconnect %)] > ...) > > I'll leave implementation as an exercise, it's not much more complicated > than the previous ones, the main trick would just be to make the macro > recursive, have it expand into: > > (let [conn1 (API1/getConnection ...)] > (try > (with-cleanup [conn2 (API2/openConnection ...) #(.disconnect %)] > ...) > (finally > (API1/closeConnection conn1)))) > > I'd probably start with a signature like this: > > (defmacro with-cleanup [[sym create cleanup & more] & body] > ...) > > Take a look at the source for with-open if you get stuck. > > > > > Coming from Java, this would be implemented as - > > > Connection1 conn1 = null; > > Connection2 conn2 = null; > > try { > > conn1 = API1.getConnection ..; > > conn2 = API2.getConnection ..; > > ... > > } > > catch (){} > > finally { > > if (conn1 != null) > > API1.closeConnection(conn1); > > if (conn2 != null) > > API2.closeConnection(conn2); > > } > > > I agree that this code doesn't look good from a purist pov, but any > > issues besides that? > > The problem here is that this breaks lexical scope, conn1 and > conn2 aren't defined outside their let block. The Java example dodges > this with mutation. Python/Ruby/JavaScript etc dodge it by having > special scoping rules: variables are scoped to functions rather than the > enclosing block. > > Clojure's opinion, as I understand it, is that it's not worthwhile > introducing mutation or special scoping rules simply to avoid some > nesting, when we have perfectly good tools (macros) for doing purely > syntactic transformations and removing boilerplate. > > There's nothing semantically wrong with nesting, it's just harder > to read. The Clojure idiom for reducing nesting is usually to use a > macro like ->, ->> or with-open to flatten it. In this case those > aren't applicable, so I suggest defining your own. > > I'm not sure I phrased that clearly, please let me know if I'm not > making sense. :-) > > Alex > > -- > 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 > athttp://groups.google.com/group/clojure?hl=en -- 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
