Re: How to handle assert() in Windows GUI apps?
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.
Re: How to handle assert() in Windows GUI apps?
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.
Re: How to handle assert() in Windows GUI apps?
Andrej Mitrovic Wrote: > Oh I'm so stupid I didn't realize my commands were outside the try > catch statement. LOL, nice joke.
Re: How to handle assert() in Windows GUI apps?
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
Re: How to handle assert() in Windows GUI apps?
Everything works fine now, please disregard my silly thread. :)
Re: How to handle assert() in Windows GUI apps?
Oh I'm so stupid I didn't realize my commands were outside the try catch statement.
Re: How to handle assert() in Windows GUI apps?
In fact throwing any kind of exception gives the same error, even if I change the exceptionHandler to not rethrow, or if I try to use show a dialog box within exceptionHandler (it won't show up). What is going on?
How to handle assert() in Windows GUI apps?
It turns out that using assert() that throws in a Windows application will show an error such as this: --- first.exe - Application Error --- The instruction at "0x00411e6a" referenced memory at "0x0044". The memory could not be "read". --- I'm not sure if this is a bug or expected behavior. If it's expected, isn't it possible to reroute assert() to use a dialog box and report the failed assert there? Here's the code, using WindowsAPI from dsource, non-unicode mode: http://codepad.org/LOvfAwSR