From: mordor.nospam@fly.srk.fer.hr   
      
   On 2012-06-06, Thomas Richter wrote:   
   >>   
   >> You can wrap the relevant (not-yet-destructed) part of the object   
   >> into the exception object and try to deal with it in catch.   
   >   
   > And where take you this object from? After all, its construction   
   > might also trigger an exception, let it be due to memory exhaustion.   
   >   
   We're drifting off: you can ask the same question for each throw   
   statement in your program.   
      
   > least the stack is unwound, so objects on the stack are most   
   > certainly gone. Objects on the heap might or might not go, but what   
      
   If the objects on the heap *do* get deallocated, then everything is   
   well: the relevant data is copied into the exception object.   
      
   >> You can copy the relevant part of the object and pass it as the   
   >> part of the exception.   
   >   
   > Where to?   
      
   To the catch() site.   
      
      
   >> STL is thus an example of using exceptions as "always on" substitute   
   >> for assert().   
   > Sorry - no, that's simply not correct. I don't know what your   
   > implementation does, but that is surely not required by the specs for   
   > operator[].   
      
   I'm not talking about operator[] -- I'm talking about many other   
   methods, for example, basic_string::insert overloads in gcc 4.1.2   
   throw std::out_of_range when given invalid indices.   
      
   > object. So what exactly does this mean? The object didn't want to   
   > die, so the attempt to delete it wasn't justified. Wait a minute -   
      
   The object *discovered* it didn't want to die. Agreed, this is   
   better handled by ordinary methods.   
      
   > What can do you about a failing fclose() in first place?   
      
   Depends. Writing data to another location might be an option,   
   for example.   
      
   > If you *must* deal with errors, then   
   >   
   > {   
   > fstream f;   
   >   
   > try {   
   > ... do all the file operations...   
   > f.close(); // I'm done   
   > } catch(...) {   
   > // handle my errors   
   > }   
   > }   
   >   
      
   This solution won't work if some of the "file operations" throws.   
   (e.g., all file-operations succeed, but you presumably do something   
   with that data and this "something" throws.) Where do you put the   
   close() that won't get executed and that might *still* throw?   
      
      
   --   
    [ 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)   
|