omnithread.h and exceptions

Brian Burton brian.burton@burton-computer.com
Tue, 27 May 1997 09:33:23 -0400


I noticed that omnithread does not use exceptions to report errors.  Is
this a deliberate design decision?  If not, I'd like to propose that the
classes be modified to report errors using exceptions.

I think this would greatly improve the interface.  For example,
omni_condition::timed_wait() could simply return a bool (TRUE if
signalled, FALSE if timed out) and throw an exception if some error
prevented completion of the call.

 try {
   omni_mutex_lock lock(mutex);
   ... do something ...
   while (!condition.timed_wait(...)) {
      ... some periodic task before trying again ...
   }
   ... condition satisfied ...
 } catch (omni_mutex_error) {
   ... mutex operation failed ...
 } catch (omni_condition_error) {
   ... condition operation failed ...
 }

This is easier to read and (with a good C++ compiler) faster than adding
additional error checking after every call.  It seems to me (please tell
me if I'm wrong) that errors on these calls should be very rare and most
likely would require fairly drastic measures to compensate for.  If so,
using exceptions makes even more sense since we can keep the main code
path uncluttered and allow exceptions to propogate fairly high in the
call chain before being handled (i.e. most code would not need a try
block).

Many other functions could be declared void since they logically don't
need to return anything (wait, signal, lock, unlock, etc).

I realize that this would require some modification to the core of
omniORB that uses the monithread library.  But I think it would be well
worth the effort in the long run by producing cleaner code.

I would be happy to offer a revised omnithread.h and an exception
heirarchy if the authors are interested.

All the best,
++Brian

-- 
Brian Burton                          Custom Software Development
Burton Computer Corporation           Java, C++, Orbix, Tuxedo
brian.burton@burton-computer.com      OO Consulting and Mentoring