Re: Good style for memory management?

[Paul Pogonyshev <pogonyshev gmx net>]

Roland Schwarz wrote:
> Paul Pogonyshev wrote:
> > Well, I do not know when you throw exceptions, but for me exceptions in GUI
> > construction are unacceptable, because GUI construction is not meant to
> > handle user input or something like that.  I.e. if they happen, I have a
> > broken program and I do not care if it is a little more broken by leaking
> > memory.  In any case it must be fixed.
> 
> It is not the question when I throw, but when code I am accessing during
> GUI construction might throw. Also that need not have to do with user
> input.
> Lets assume you are loading from an external file some customizable data
> that is needed during GUI startup. Lets further assume you use a parser
> that if finding an error in the file throws out. Since you are not the
> author of the parser you either have to
> *) wrap everything in try {} catch() {} blocks or use
> *) resource acquisition is initialization idiom.
> 
> As you can see nothing in my program is "broken" in your sense, that
> needs to be fixed, but something outside, i.e. the parsed configuration
> file.
> 
> Nevertheless I would consider a program that cannot cope with this fact,
> but instead silently leaks being broken. (But in a different way as I
> think you are suggesting.)

Well, I consider a program that starts building GUI piece and fails due to
what you deem a non-critical error broken.  Either it should finish and
report error in e.g. a message box or not start at all.  And if the error
_is_ critical, I frankly do not care if it leaks.

> Is this understandable what I am trying to say?

Yes it is.  But easiest solution in your case is not to mix GUI construction
with data retrieving.  Because otherwise you will tend to write tons of code
just to make sure your program never leaks, even if something is badly broken.

Paul