On 28.1.2016. 21:02, Emil Dotchevski wrote:
Have you considered using Boost Exception? It lets you add arbitrary data
to exception objects, even after they have been thrown, regardless of their
type -- see
http://www.boost.org/doc/libs/release/libs/exception/doc/error_info.html.
The general idea is to adopt a strategy where the exception objects are
augmented with any, even platform-specific relevant data, which then the
catch site can analyze to choose the correct handling.
Hopefully these efforts will bring us to a solution that will do away
with the, IMO, false dichotomy between "errors" and "exceptions"
( vs <exception>) - rather we will start thinking only
about "errors"/error objects which can be transfered in two different
ways - like a ball in a rugby game - it can be passed 'on foot' hand to
hand or it can be thrown over intermediate players to its final
destination (only with errors its in reverse - they are mostly
passed/returned or thrown 'backwards':).
IOW things like error_info will be applicable to 'the' standardized
error type(s) that functions also return, not just throw.
--
"What Huxley teaches is that in the age of advanced technology,
spiritual devastation is more likely to come from an enemy with a
smiling face than from one whose countenance exudes suspicion and hate."
Neil Postman
