On Sun, Nov 30, 2008 at 5:52 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Any other solutions that would avoid a helper function? Not just
> for my particular case, but anytime that one is calling recur from a
> catch clause?
Generally, collect the information you need from the catch clause and
return it to a context where recur can be called if needed.
(defn prompt-for-int [prompt junk-allowed default]
(let [input (prompt-read prompt)
num (try (Integer/valueOf input)
(catch Exception _ :fail))]
(if (= num :fail)
(if junk-allowed
default
(recur prompt junk-allowed default))
num)))
Note that the above ugliness is caused at least in part by a mismatch
between the Java API and Clojure idioms. If 'Integer/valueOf' were a
Clojure function, I would expect nil to signal an error and any
Integer returned to be valid:
(defn parse-int [string]
(try (Integer. string) (catch Exception _)))
This would allow for a much cleaner definition of prompt-for-int:
(defn prompt-for-int [prompt junk-allowed default]
(or (parse-int (prompt-read prompt))
(if junk-allowed
default
(prompt-for-int prompt junk-allowed default))))
Or, since a default only makes sense if it might be returned:
(defn prompt-for-int
([prompt] (or (prompt-for-int prompt nil) (recur prompt)))
([prompt default] (or (parse-int (prompt-read prompt)) default)))
--Chouser
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
