@cfleming thanks

As a design path, would there be good reason not to ultimately accept into the clojure trunk, a fork that wraps exceptions with a higher-level function or macro that provides some extra machinery? I was thinking of something like picking up exception text from a lookup table, rather than hardwiring it, this macro/function being able to do some extra things: • lookup tables are swappable, so can be used for providing different messages for localization or adaptation to a certain audience. • exceptions in development mode, can be served with a prompt or button, or default by configuration ― to report their text or suggest an improvement to a cloud server. it is kind of time that we use automated feedback and (big) data for improving our programming languages not only for our applications. • equivalently, the former feature can be used to funnel exceptions from a class, to a group server for a tutor responding or reviewing them and similar social purposes. More importantly/usefully, this also allows one to funnel exceptions to monitor tools, in a clean integrated manner (maybe the macro/function can take a program-configuration-level fn to perform exception side-effects). Naively, the downsides I initially see are: 1. searching the internet for an exception will have to rely on an exception ID and version. 2. implied from (1) exception id's are then needed to convey unique error situations ― rather than their text. 3. anything left to Java to default on, will not be handled here ― e.g. you'd still get a null pointer exception when using a non-function var in call position. 4. some blogs, JIRA items, and books will gradually obsolete with regard to mentioning specific error text. 5. maybe the major undesirable side-effect: tools that already juggle exceptions ― namely various pretifiers, IDE integrations and other custom-made exception handling solutions ― will eventually need, or benefit from, being adapted, or API may need to support both the old and new language behavior for a while to ease their transition; On first thought, the new macro/function can cater for that compatibility though! What other complications and downsides do you foresee here?

Many of the problematic exceptions, in terms of intelligibility, aren't just a question of a bad message, there's the much harder problem of the compiler or runtime code even knowing what really went wrong. See for example this classic:

user=> (into {} '[(:a 0) (:b 1)])
ClassCastException clojure.lang.Keyword cannot be cast to java.util.Map$Entry  clojure.lang.ATransientMap.conj (ATransientMap.java:44)