Fork me on GitHub
#clojure-dev
<
2022-02-03
>
quoll18:02:48

A question on parse-uuid… I note that parse-long, parse-double and parse-boolean will all throw an IllegalArgumentException if they are provided anything other than a string. However, parse-uuid doesn’t test for this, and so it will throw a ClassCastException if provided with something that isn’t a string. It’s an exception either way, but it seems inconsistent. Is there a reason for this inconsistency, please?

quoll18:02:05

The parsing functions that test will all call the internal function parsing-err to describe the problem, but parse-uuid just lets it fall through

Alex Miller (Clojure team)18:02:40

the philosophy here is that the parse- functions are defined for strings. for non-string, behavior is undefined.

Alex Miller (Clojure team)18:02:00

they happen to throw exceptions in these cases but the type is not prescribed

Alex Miller (Clojure team)18:02:50

so you are free to do anything in cljs in these cases - I'd recommend throwing but don't care what specifically is thrown

quoll18:02:06

I was looking to duplicate the behavior, and for each of them I’m testing with

(if (string? s)
  ...parse...
  (throw (js/Error. (parsing-err s))))
But when I got to parse-uuid I noticed that it’s not like this, so I thought I’d check if that’s how you actually intended it to be

Alex Miller (Clojure team)18:02:27

what the docstring says is what we commit to and these docstrings don't mention what happens if you give it something other than a string (I'd spec them as taking string?)

👍 1
souenzzo01:02:59

why not throw an ex-info, on both clj and cljs?

quoll02:02:56

On clj, it’s up to the core team, but it really is an illegal argument. It should never be passed. And other functions (that predate ex-info) were already doing this. So it makes sense that they would continue to take this approach. The core abhors changing behavior, and for new functions to be consistent with existing ones matters. On cljs, I’m following precedent, meaning that I’ll throw an exception just like clj does, and also I’m throwing the same kind of exception that other parts of cljs.core throws when clojure.core throws IllegalArgumentExceptions