reducing runtime errors due to mistyped keywords

9 views
Skip to first unread message

Istvan Devai

unread,
Apr 22, 2010, 1:43:42 PM4/22/10
to clo...@googlegroups.com
Hi!

In general, what to give greater attention if I'm getting lots of
runtime errors due to mistyped keywords? (eg. I'm referencing a map
where the keyword is non-existent and this nil value goes deep down into
my code where it is very hard to see that this was caused by a
non-existing map entry).

Are there some constructs that allow catching some of these errors
compile time or ease debugging runtime?

Cheers,
Istvan

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Jason Wolfe

unread,
Apr 22, 2010, 2:44:02 PM4/22/10
to Clojure
Hi Istvan,

I've run into this a fair bit too. To catch such problems (at
runtime), I sprinkle my code with (safe-get m :key) in key places,
rather than (:key m) or (m :key) or (get m :key). safe-get:


(defmacro lazy-get
"Like get but lazy about evaluating default"
[m k d]
`(if-let [pair# (find ~m ~k)]
(val pair#)
~d))

(defn safe-get
"Like get but throw an exception if key not found"
[m k]
(lazy-get m k
(throw (IllegalArgumentException.
(format "Key %s not found in %s" k m)))))

It's not ideal though, especially since I'd imagine you won't get fast
access for new defrecords.

I think it might be nice if one could optionally make "closed" maps or
records, which throw when you try to get a missing key rather than
returning nil. I'm not sure what the implications of this would be,
though. Maybe others have more elegant solutions...

-Jason


On Apr 22, 10:43 am, Istvan Devai <ist...@istvandevai.com> wrote:
> Hi!
>
> In general, what to give greater attention if I'm getting lots of
> runtime errors due to mistyped keywords? (eg. I'm referencing a map
> where the keyword is non-existent and this nil value goes deep down into
> my code where it is very hard to see that this was caused by a
> non-existing map entry).
>
> Are there some constructs that allow catching some of these errors
> compile time or ease debugging runtime?
>
> Cheers,
> Istvan
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.To post to this group, send email tocl...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your first post.
> To unsubscribe from this group, send email toclojure+...@googlegroups.com

Laurent PETIT

unread,
Apr 22, 2010, 4:28:05 PM4/22/10
to clo...@googlegroups.com
A foolish idea out of my head :

For qualified keywords, e.g. :ns.part/name-part, check, *if the
current ns does not correspond to ns.part, that the keyword already
exist. And / or add a directive to explictly "declare" a qualified
keyword (that is, without having the compile-time check exception
thrown).

For non qualified keywords, e.g. :bare-name , keep as is.

Certainly one of those wrong right ideas, but thought I should share
(I like to be bashed :-) )

2010/4/22 Jason Wolfe <jaw...@berkeley.edu>:
Reply all
Reply to author
Forward
0 new messages