Per

This syntax error reports incorrectly as an execution error:

The data reader function for uuids uses a precondition string? which fails with an AssertionError, falls through the reader and is assumed to be a runtime error.

We would prefer this to report as a reader phase error. so this drives the question of how reader functions should be expected to report a read error. Within the reader, a variety of RuntimeException flavors are thrown, generally the LispReader catches Exception and rethrows as LispReader.ReaderException, which is caught by the compiler to tag as a read phase error. Because AssertionError is not an Exception subtype, it flows through without being caught.

Some options:

• Don’t use preconditions to validate in uuid data reader function (should check others too)

• Catch AssertionError (or Throwable etc) either when reading tagged literals or more broadly and coerce to LispReader.ReaderException as we do with others.

Whatever we decide here, we should be a little more prescriptive about data reader fns in the docs.

Existing data reader fns in core:

• clojure.uuid/default-uuid-reader - precondition will throw AssertionError, UUID/fromString throws IllegalArgumentException

• clojure.instant/read-instant-date - NumberFormatException

I surveyed many Clojure community data reader functions and all of the cases I reviewed throw RuntimeExceptions.

Proposed:

Stop using a precondition in default-uuid-reader and instead use an explicit check in the body that throws a RuntimeException or subclass. Document expectations in .

Patch: clj-2726.patch

Screened by: fogus