Liste des Groupes | Revenir à cl c++ |
On 04.01.2025 04:06, Sam wrote:Paavo Helde writes:
Anyway, avoiding uncaught exceptions is easy, one just has to place
catch(...) in main() and in all thread functions. Problem solved.
Sure, catch(...) deals with it. But it gives you nothing useful to work
with. A valiant attempt to send a bat-signal to std::current_exception
will eke out a few useful bits, if one's lucky, but the end result will
just be more spaghetti code.
If an exception has reached the top-level catch, then this means that
all lower levels (which have more knowledge about the context) have not
been able to catch and handle it. In the top-level catch there is little
hope I could do anything smarter, typically I just need to report or log
an error message.
So there is no need to differentiate between different types of
exceptions or to extract any useful bits from them, all I need is an
error message. For that I have a little helper function which can be
called from inside catch(...) and which handles various exception base
classes and falls back to typeid(e).name() for unknown types. Actually I
am not interested in exception types at all at this point, not to speak
about enforcing them somehow. If there appear new exception base
classes, I add support for them in the helper function, not trying to
reduce their usage.
[...]
I dunno, maybe something like:
typedef throws(ClassA, ClassB) AlgoThrownClasses;
Then you go ahead and declare your algorithm:
void my_algorithm(algorithm_info_t &) throws(AlgoThrownClasses)
That's the first good idea from you in this discussion. I still do not
see much point in exception specifications, but such a typedef would at
least make life easier for me on this Alternate Earth.
PS. Nowadays they prefer `using` instead of `typedef`.
Les messages affichés proviennent d'usenet.