www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Re: How to handle assert() in Windows GUI apps?

reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On 2011-04-07 14:19, Andrej Mitrovic wrote:
 Everything works fine now, please disregard my silly thread. :)

Well, whatever you're doing, you almost certainly shouldn't be catching Errors (AssertErrors or otherwise). That's generally a very bad idea. Very little cleanup is done when Errors are thrown. finally blocks get skipped. scope statements get skipped. Destructors get skipped. Etc. So, once an Error is thrown, it takes very little for the program to be in an invalid state. - Jonathan M Davis
Apr 07 2011
next sibling parent Kagamin <spam here.lot> writes:
Jonathan M Davis Wrote:

 On 2011-04-07 14:19, Andrej Mitrovic wrote:
 Everything works fine now, please disregard my silly thread. :)

Well, whatever you're doing, you almost certainly shouldn't be catching Errors (AssertErrors or otherwise). That's generally a very bad idea. Very little cleanup is done when Errors are thrown. finally blocks get skipped. scope statements get skipped. Destructors get skipped. Etc. So, once an Error is thrown, it takes very little for the program to be in an invalid state.

hmm, docs say different things:
 If code detects an error like "out of memory," then an Error is thrown with a
message saying "Out of memory". The function call stack is unwound, looking for
a handler for the Error. Finally blocks are executed as the stack is unwound.
If an error handler is found, execution resumes there. If not, the default
Error handler is run, which displays the message and terminates the program.

Apr 08 2011
prev sibling parent Jesse Phillips <jessekphillips+d gmail.com> writes:
On Fri, 08 Apr 2011 07:29:37 -0400, Kagamin wrote:

 Jonathan M Davis Wrote:
 
 On 2011-04-07 14:19, Andrej Mitrovic wrote:
 Everything works fine now, please disregard my silly thread. :)

Well, whatever you're doing, you almost certainly shouldn't be catching Errors (AssertErrors or otherwise). That's generally a very bad idea. Very little cleanup is done when Errors are thrown. finally blocks get skipped. scope statements get skipped. Destructors get skipped. Etc. So, once an Error is thrown, it takes very little for the program to be in an invalid state.

hmm, docs say different things:
 If code detects an error like "out of memory," then an Error is thrown
 with a message saying "Out of memory". The function call stack is
 unwound, looking for a handler for the Error. Finally blocks are
 executed as the stack is unwound. If an error handler is found,
 execution resumes there. If not, the default Error handler is run,
 which displays the message and terminates the program.


Out of memory is somewhat special. It is supposed to be an Exception, but is an Error so that memory can be allocated in a nothrow function. It is also a much larger issue than most Exceptions as it can't be ignored like other exceptions.
Apr 08 2011