🚀 go-pugleaf

In article <KANZE.92Oct7151332@slsvdnt.us-es.sel.de>, kanze@us-es.sel.de (James Kanze) writes:
|> This leads to my basic premise.
|> 
|> Objects in a general library should not throw exceptions at all.  The
|> how and what of exception handling is *always* application specific,
|> and if a library like the iostream starts throwing exceptions, it
|> forces *all* applications that use it into its mould.
|> 
|> The solution I prefer is call-back functions.  The default failure
|> action is always to terminate the program with an error message.
|> Since this occurs near the point of the error, the error message can
|> actually be quite meaningful.  In failsafe applications, the user
|> replaces the default error function with one of his own, which may
|> very well (probably will) throw an exception.  This will be an
|> exception designed by the user however, and not one imposed by the
|> library.  The choice of whether one or many exception classes, etc.,
|> and in what class hierarchy they are, can then be made in an
|> application specific manner by the user.

Sorry to waste bandwidth on such a short follow-up, but I just want to
re-enforce James' premise and his call-back solution.  Let the client of a
general library choose what type of action to take for an error in a
general-purpose library.  Using this mechanism for the default allocator
would allow a GUI-based application to automatically display an "Out of
Memory" message and terminate, for example, rather than raise an exception.

-- 

- Pablo

------------------------------------------------------------------------
Pablo Halpern             (617) 290-3542
HP Waltham                pabloh@hpwarq.wal.hp.com

I am self-employed, so my opinions *do* reflect those of my employer.
However, they may not reflect the opinions of my client.
------------------------------------------------------------------------