95d15094   
   From: dave@boostpro.com   
      
   on Fri Nov 11 2011, "gast128-AT-hotmail.com"  wrote:   
      
   >    
   >   
   >> >> It's very easy to handle every error, though: just put a try/catch(...)   
   >> >> block in main.   
   >>   
   >> > Not for GUI applications.   
   >>   
   >> Yes, for GUI applications.  At least, for the ones I've built.  You put   
   >> the try/catch in the mechanism that initiates commands.   
   >   
   > There is even more. Also the non modifying parts (e.g. the view part)   
   > can have references to non existing parts.  This shouldn't be happen,   
   > but those things happen in practice.   
      
   All kinds of bugs happen in practice.  I don't know what this has to do   
   with anything we're discussing.  Exceptions are almost never the best   
   way to deal with bugs anyhow.   
      
   >> > Btw the try/catch is the easy part. Rollback with transaction   
   >> > semantics is the difficult part as you already mentioned yourself.   
   >>   
   >> Actually, if your application supports an "undo" command, you probably   
   >> already have all the tools you need.   
   >   
   > This is from the GOF book.  Unfortunately for larger applications   
   > these text book examples won't work that easy.   
      
   Huh?  No, I was doing that in a fairly large GUI app years before GoF   
   was published.   
      
   > In our case the application is divided in layers and within the layers   
   > you have subsystems. These subsystems have to be synchronized between   
   > each other. The 'undo' command would span multiple subsystems and they   
   > have to stackup all undo information as well. Files may not be deleted   
   > (only marked for purging), because an undo command may rollback to the   
   > original situation. Using the memento pattern would be too heavy.   
      
   I don't believe in "Design Patterns" (so sue me).  I didn't   
   intentionally use any of those patterns, either.  Actually when did I   
   get the book I spent several weeks trying to "apply" patterns to my   
   application until I realized I was overly-decoupling and   
   prematurely-generalizing the code to the point where I was adding a   
   great deal of needless complexity.  I was much happier and more   
   productive when I put that stuff behind me.   
      
   > We did consider undo / redo, but in the end we decided that it became   
   > too heavy without much roi.   
      
   Ah, well then, you missed an opportunity to get high ROI because the   
   infrastructure for error recovery and undo have a huge overlap.   
      
   >> You're still not answering the question: fatal to what?  Yes, an   
   >> otherwise-unhandled exception should terminate the current command, but   
   >> it shouldn't necessarily have to terminate the program.   
   >   
   > Yes but this was the original discussion. What happens if u miss the   
   > exception (or return statement).   
      
   You simply don't miss it, the same way you don't miss writing a main()   
   for your program.  A single catch-all block can handle triggering the   
   rollback mechanism.  In the case where you truly need several try blocks   
   there's a trick you can use to avoid replicating all the logic in the   
   associated catch.   
      
   >> > For fatal they can terminate the application. Last category would be   
   >> > things like bad_alloc.   
   >>   
   >> There's no reason bad_alloc needs to be fatal to the application.   
   >   
   > No but memory depletion is very hard to handle.   
      
   Meh. Allocate yourself a reserve memory block at the beginning so you   
   free it when memory runs out and complete your recoery.   
      
   > Mostly this comes due to memory leaks so the memory cannot be   
   > reclaimed.   
      
   IMO your biggest problem is that you're trying to write code with the   
   assumption that everything around is buggy.  That's simply impossible in   
   a program of any significant scale, and it leads to more complicated   
   code, more bugs, and makes existing bugs harder to find.  If you want to   
   make this system robust and avoid growing old before your time, you need   
   to stop operating that way (again, IMO).   
      
   > Even when one does gracefully exit the application, there is hard   
   > change that during this process dynamic memory is needed (which will   
   > fail then).   
      
   See above.   
      
   > I do not write mission critical systems,   
      
   Me neither.   
      
   > but I thought that I have read that some of them (e.g. the mars rover)   
   > just forbid memory allocations in the first place (so preallocate in   
   > front), and thereby never get in the bad_alloc situation.   
      
   Some do.  Some use separately-designed redundant functionality,   
   "voting," and other techniques to deal with unexpected situations.   
      
      
   --   
   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)