home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c++.moderated      Moderated discussion of C++ superhackery      33,346 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 32,374 of 33,346   
   Zeljko Vrba to Thomas Richter   
   Re: Will we ever be able to throw from a   
   06 Jun 12 17:01:24   
   
   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)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca