9c218f6e   
   From: dave@boostpro.com   
      
   on Thu Nov 03 2011, Castor Nageur wrote:   
      
   > Hi all,   
   >   
   > I am using an API exporting many classes and each class export many   
   > methods. Each method is throwing some "APIException" exception   
   > instance when something goes wrong. We are not very happy with this   
   > because our developpers use to forgetting catching the exceptions so   
   > many applications crash because of this.   
      
   Writing exception-safe code is not about catching exceptions; it's about   
   maintaining invariants. If your applications are crashing the cure is   
   almost certainly not (primarily) to add more catch blocks. Usually one   
   catch block at the outer level of an application (in its "main loop") is   
   sufficient.   
      
   > I can not modify the API (this a third-party API) so my code must not   
   > be intrusive.   
   >   
   > I would like to find an elegant way to surround each API method call   
   > with a try/catch then return the exception code as the error code like   
   > this:   
   >   
   > void mynewclass::mynewmethod(... /* API method arguments */, int &err)   
   > {   
   > try   
   > {   
   > class.method(... /* API method arguments */);   
   > }   
   >   
   > catch(APIException e)   
   > {   
   > err = e.getErr();   
   > }   
   > }   
   >   
   > class::method() is the API implementation and   
   > mynewclass::mynewmethod() would be the new API surrounding   
   > implementation.   
   >   
   > In order to implement this, I was thinking of using a C++ template but   
   > I can not imagine writing a template for each of the hundred of   
   > different method's names defined in the API.   
   >   
   > Consequently, I am looking for a simple and short code converting the   
   > exception throwing mechanism by the (plain old) error code returning   
   > mechanism.   
      
   If you're determined to go this way, there are some things you can do,   
   but none of them are what I'd call "elegant," and I don't think they   
   would solve your underlying problem, because merely changing the error   
   reporting system is not enough to get people to write code that handles   
   errors properly. The very best thing you can do is to teach your people   
   how to handle errors while maintaining program invariants, and usually,   
   that job is actually easier to do with exceptions than with "err" codes.   
      
   --   
   Dave Abrahams   
   BoostPro Computing   
   http://www.boostpro.com   
      
      
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
    [ comp.lang.c++.moderated. First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|