Re: Necessity of multi-level error propogation
On Mar 14, 1:26 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* Annie Testes:
Tony wrote:
[...]
Almost. It's certainly possible to make error-propagation
more reliable than in C, but I don't know whether it can be
made as reliable as exceptions. Mandatory error codes are
a first step, but a programmer may still forget to pass them
to the caller. Which kind of technique would you use to
ensure the error code is transmitted during stack unwinding ?
I'm not sure (I often have problems grokking Tony) but I think
perhaps he's thinking of something like Barton & Nackmann's
Fallible, a return value that is a struct that can be
logically "empty", where accessing the carried value in a
logically empty one terminates or invokes some installed error
handler or throws an exception. For an exception free scheme
it would have to terminate or invoke error handler.
Essentially that would be /imposed/ checking of return values,
not especially good with respect to code structure or
efficiency, but at least avoiding the problems of return
values not being inspected by caller.
Not really Fallible, since his idiom doesn't necessarily suppose
a return value other than the return code. It's another very
old idiom (I think I was using it even before I learned
Fallible), although I can't remember ever seeing a name for it
(Smart return codes?). Basically, something like:
template< typename Status >
class ReturnStatus
{
public:
/* not explicit! */ ReturnStatus( Status status )
: myStatus( status )
, myIsRead( false )
{
}
ReturnStatus( ReturnStatus const& other )
: myStatus( static_cast< Status >( other )
, myIsRead( false )
{
}
~ReturnStatus()
{
assert( myIsRead ) ;
}
ReturnStatus& operator( ReturnStatus const& other)
{
ReturnStatus tmp( other ) ;
swap( tmp ) ;
return *this ;
}
void swap( ReturnStatus& other )
{
std::swap( myStatus, other.myStatus ) ;
std::swap( myIsRead, other.myIsRead ) ;
}
operator Status() const
{
myIsRead = true ;
return myStatus ;
}
private:
Status myStatus ;
mutable bool myIsRead ;
} ;
It's fairly easy to imagine scenarios where it fails to protect
(an object destructed without the return code having been
correctly handled), but such cases probably don't occur too
often in real code, and it does offer a fair amount of protect
against forgetting to check the return code.
If he's thinking of Fallible then pointing that out to James
would be sort of misplaced.
For James is the one who usually argues for using Fallible
(when appropriate)...
:-)
I argued a lot for the above as well, in the distant past,
before we had exceptions. Today... almost all of the cases
where it would be appropriate are better handled by exceptions,
so it's an idiom (or pattern) that ceased to be "usual" or
relevant before patterns started getting named. (And thus,
before a lot of readers here started using C++.)
(BTW: the implementations I've used didn't use the swap idiom
for assignment, for the simple reason that the idiom hadn't been
invented when this idiom was frequent. And the assignment
operator was often a source of errors.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34