Ok, I solved this. What I had to do was put a '*do*' around the surrounding parent block (line 54). I only started looking at the surrounding block when I put en extra line of execution below my problem area (line 67), and saw the NullPointerException move down there. Now I understand the point that that article was making - Clojure will try to execute the results of the first operation in a list. The rest of the calls, in this case, would be parameters to the 'nil' returned by 'apply' (line 55).
54 (*do* ;; execute 'if' block 55 (.. node getCommandInput (apply this) ) 56 57 58 (if (. (isa? (class (. node getCommandInput)) com.interrupt.bookkeeping.cc.node.AOptsCommandInput) booleanValue ) 59 (do (println "OPTIONS input")) 60 ) 61 62 63 (if (instance? com.interrupt.bookkeeping.cc.node.AXpathCommandInput (. node getCommandInput) ) 64 65 (println "XPATH input") 66 ) 67 (do (println "qwerty")) 68 ) Cheers Tim On Mon, May 24, 2010 at 5:03 AM, Meikel Brandmeyer <m...@kotka.de> wrote: > Hi, > > On Sun, May 23, 2010 at 10:37:29PM -0400, Timothy Washington wrote: > > > I wave a strange NullPointerException when I call (println "Some > string"). > > It seems similar to this problem on > > Stackoverflow< > http://stackoverflow.com/questions/1530555/nullpointer-in-clojure-when-running-doseq-with-multiple-expressions-in-the-body > >, > > but the 'do' solution doesn't seem to work for me. In the output below, > the > > "XPATH..." output is obviously being called. > > The solution there is not the do, but the removal of the superficial > parens. > > > It has something to do with the 'if' block b/c when I i) printout the > 'isa' > > condition outside of the block, it evaluates to true" > > (println (isa? (class (. node getCommandInput)) > > com.interrupt.bookkeeping.cc.node.AXpathCommandInput )) > > Normally, you use instance? for this test. > > (instance? c.i.b.c.n.AXpathCommandInput (.getCommandInput node)) > > > Also, if I ii) replace line 67 with "somestring", then the > > 'NullPointerException' moves up to the if block (which all evaluates to > > true). Very strange, but it's probably something known, that I'm missing. > > I don't see a hint in the stacktrace you provided that points at the > print. The movement of the Exception when changing the print to a string, > also supports that hypothesis. You probably do something with the value > of the if, which is nil because println returns nil (ie. Java null). > And/Or you have another nil somewhere in the surrounding code. As it > stands the code itself should work fine. > > You check whether it is the println by doing a (if false (println ...)). > > Sincerely > Meikel > > -- > 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<clojure%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://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
