@richiardiandrea Isn't the concern there more than you need to not display ex-data values "as-is" to anyone?

It would be the same as any other ex-info you throw -- it could well include sensitive data in some context...

that's a tough one, because then my display thing needs to know about what is displaying

aka, I need to call dissoc on things, maybe it should

I wouldn't expect production code to just display any spec failure as is -- those exceptions are intended for code, not humans, and certainly not end users.

FWIW, our application error logging/reporting code has always contained logic to strip known, sensitive fields from any data logged or reported, long before spec was a thing...

ok yeah maybe that's something I would need to do anyways

I wonder though if things change ...say the string for password changes now I need to change spec AND dissoc

@richiardiandrea That's a good reason to use a globally-unique qualified key name 🙂