class problem {
const char *msg;
public:
// when a problem is constructed using a string
// set msg to that string and do nothing else:
problem (const char *s) : msg(s) {} ;
// when somebody wants to find out what to print...
const char *what_to_print() {return (msg);} ;
}
void g () {
... // Omigosh, trouble ...
throw problem ("out of special memory");
}
void main () {
...
try {g();}
catch (problem foul_up) {
cout << foul_up.what_to_print()}
... // and take remedial action
}
}
The exception handling mechanism is an important part of coding big projects.
All compilers other than the SGI native C++ handle try/catch/throw correctly.
(A beta-version patch to the SGI CC allows a -exceptions
option to support basic
exception handling. The presence of this patch does not affect our interim
recommendations but is an indication that SGI is moving toward suitable
compliance.) A newer mod to the specification allows listing, in a routine, the
exceptions it is allowed to pass along; anything outside that list gets changed
to an ``unknown'' exception before being passed upward. Except for AIX and
WATCOM (and the patched SGI native CC), the compilers that handle exceptions
appear to do this properly as well.
Our recommendation is that C++ exception handling be used freely wherever its functionallity is appropriate. (Note that the presence of exception handling code may, in current compiler implementations, adversely affect performance. These issues are getting better, but it is and will always be right to think through that tradefoff when deciding whether increased exception handling detail is appropriate or not.)
There is no clean workaround for a compiler that does not at least accept the syntax used for the exceptions. We will not recommend or sanction a compiler which does not handle exceptions in the standard way. However, if there is an option to enable accepting the proper try/catch/throw syntax available for a compiler, then that compiler is suitable for interim use even if the implementation of exception handling is slow or not quite ANSI compliant.
This implies that for now, any development on an SGI or IBM RS/6000 platform should utilize g++ instead of the native vendor C++ compiler which does not accept the try/throw/catch syntax.