• Andrej Mitrovic (9/9) Apr 07 2011 It turns out that using assert() that throws in a Windows application wi...
• Andrej Mitrovic (4/4) Apr 07 2011 In fact throwing any kind of exception gives the same error, even if I
• Andrej Mitrovic (2/2) Apr 07 2011 Oh I'm so stupid I didn't realize my commands were outside the try
• Kagamin (2/4) Apr 08 2011 LOL, nice joke.
• Andrej Mitrovic (1/1) Apr 07 2011 Everything works fine now, please disregard my silly thread. :)
• Jonathan M Davis (8/9) Apr 07 2011
• Kagamin (2/11) Apr 08 2011
• Jesse Phillips (5/25) Apr 08 2011 Out of memory is somewhat special. It is supposed to be an Exception, bu...

Andrej Mitrovic <none none.none> writes:

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 "0x00000044". 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

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

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?

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

Oh I'm so stupid I didn't realize my commands were outside the try
catch statement.

Kagamin <spam here.lot> writes:

Andrej Mitrovic Wrote:

 Oh I'm so stupid I didn't realize my commands were outside the try
 catch statement.

LOL, nice joke.

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

Everything works fine now, please disregard my silly thread. :)

"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

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.

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.