"Barry Kelly" <✉eircom.net> wrote in message
news:✉4ax.com...

>
> I'm afraid I'm the reverse; exceptions *force* you to consider the
> possibility of errors.

so, isn't that pretty dictatorial?

> Error codes are optional; an awful lot of code
> can be written without regard for the error codes returned, and thus
> will continue on blithely unaware of error conditions, mucking up state,
> causing instability that isn't detected possibly for days, leading to
> lots of $$$ loss.

But errors are relative - one program's error can be another program's
"don't care" (with respect to a generic library service). For example,
say you call WinAPI functions to read out version info from a set of DLL
files. If you are merely preparing information for you About box you may
decide to ignore errors and simply print "Not found" for missing version
info resources. In a configuration management program this is however
critical and you may want to raise hell about it.
I'd hate for those functions to *always* slap me with an exception for it
though. A low-key error code is fine.


It all depends on specification.
So, depending on how you *intend* your code to work, but also depending
on third party libraries, you may have to do a hell of a lot of exception
quenching in the low level interfaces.
If you basically consider that *every* function call in principle can
fail, and treat the return codes with appropriate respect, you are no
less safe than with exceptions. I don't need exceptions to remind me that
code can fail.


Kristofer