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

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

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

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

Thanks

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))))

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?)

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

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