By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,234 Members | 1,941 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,234 IT Pros & Developers. It's quick & easy.

RAII Design Patterns and Alternatives

P: n/a
Scenario: A GUI program is developed such that the startup sequence is
controlled by the instantiation of a key object which instantiates other
objects etc. until it finally arrives at the point where it is waiting in
the message loop for messages to be put in its queue.

That is, unless something goes wrong during one of those object
instantiations in the program startup processing! Say somewhere in the
middle of all that startup processing, something does go wrong. Well, if the
objects were built with the RAII/exception architecture, the stack would
unwind back to the catch point. At which point, just maybe, an error would
be logged and the program would abort.

Or maybe, knowing that the OS is going to clean up resources for us when the
program aborts, maybe it is a lot simpler just to program the objects so
that they log and abort (sans exceptions) whenever they encounter error.

Whaddaya think?

John
Mar 10 '07 #1
Share this Question
Share on Google+
1 Reply


P: n/a
JohnQ wrote:
Or maybe, knowing that the OS is going to clean up resources for us when
the program aborts, maybe it is a lot simpler just to program the objects
so that they log and abort (sans exceptions) whenever they encounter
error.

Whaddaya think?
Write code ready to be refactored and upgraded. That means never rely on the
Memory Fairy today, if tomorrow a given method might move inside a loop, and
then cause a runaway leak.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Mar 10 '07 #2

This discussion thread is closed

Replies have been disabled for this discussion.