It would require a shift from "this API is for returning best offers"
It requires both. As long as you have options for action, you need primitive numbers, sure. Done. But as soon as there's a possibility that text needs to appear somewhere at the top, you also need a transport mechanism for that number and any other information collected along the way.
I do not think a single library or a single "mechanism" for reporting errors
All conceivable error-handling mechanisms have two things in common. They all have to convert infos to text. And they need safe collect and transport. Since the collected information is of unknown—and in any case, varying—types, the transport mechanism must be a heterogeneous container.
For security or business-safety reasons you do not explain in detail
That can be done at the handler, the info-to-text-converter, because it can ask the infos themself or look for its types. As far as I can tell, all the processing mechanisms I know of that go beyond primitive types suffer from one flaw: they are not error-free themselves. However, this is a prerequisite for ensuring that I don't have to deal with other errors during error handling. If a piece of information cannot be added, then `push_back()` must not throw under any circumstances. There must be no further errors between the detection of the error condition and the processing of the error object. Any error that occurs must be catched. The transport has to be error-neutral. -- Mit Radwegen lernte ich den Menschen kennen. http://radwege.udoline.de/ GPG: A245 F153 0636 6E34 E2F3 E1EB 817A B14D 3E7E 482E