On Mon, Feb 16, 2009 at 12:25 AM, David Nolen <dnolen.li...@gmail.com> wrote:
> (defmethod assert-expr 'raised? [msg form]
> (let [error-type (second form)
> error-meta (meta (find-var (qualify-sym error-type)))
> error-str (str (ns-name (:ns error-meta)) "/" (:name error-meta))
> body (rrest form)]
> `(with-handler
> (do
> ~...@body
> (report :fail ~msg '~form (str ~error-str " not raised.")))
> (handle ~error-type {:as err#}
> (if (= (:tag err#) (symbol ~error-str))
> (report :pass ~msg '~form nil)
> (report :fail ~msg '~form (str ~error-str " was raised."))))
> (handle *error* {:as err#}
> (report :fail ~msg '~form (:tag err#))))))
>
> Here is the macro that seems to work, any improvements much appreciated ;)
Well, since you're asking... :-)
I don't quite understand why you got through all that work to get
error-str -- isn't it just (str (qualify-sym error-type))?
...and since you then use it only as an arg to 'symbol' or 'str', you
could just use the symbol itself instead of converting it to a string
and back.
> This fails when no error is raised, when the wrong error type is raised, and
> I believe it's captures errors which are derived but not the exact error (is
> this a weird behavior?).
I'm not sure, but I think you'd want to allow an implementation to
change to a derived error type without breaking the tests. But I
could be wrong -- it should probably behave the same as the 'throws?'
method, since Java Exceptions also do inheritance.
> Much nicer than those ugly Java Exceptions, no? ;)
Sure, looks good to me. Would it ever be useful to test that the
error has a particular set of arguments? I guess that may be more
detailed than any test would want to get.
It would also be interesting to try to test for the existence and
behavior of any 'continue' forms.
> On a last note, I've found your qualify-sym fn quite handy and have been
> using it elsewhere ;)
Really!? I'd never needed it before error-kit, and I'm pretty
suspicious of needing it even there. I think I'd rather just use Vars
for error tags, but they're not currently allowed in the Clojure
inheritance hierarchies. If Vars were Named, I think it would work,
and it's not at all clear to me why they aren't, since they have a
namespace and a name just like symbols and keywords do. Rich is
probably too busy with lazier just now, but I intend to be annoying
about this at some later date.
--Chouser
--~--~---------~--~----~------------~-------~--~----~
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
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
-~----------~----~----~----~------~----~------~--~---
