www.digitalmars.com         C & C++   DMDScript  

D - assert

reply "Vathix" <Vathix dprogramming.com> writes:
Should assert() be avoided in a win32 gui app? All the user will see is the
program terminating for no reason.. or maybe there could be a way to define
what assert will do? like...

assert(fromCompiler)
{
    MessageBoxA(null, toStringz(fromCompiler), "assert!", MB_ICONERROR);
    /*
        write to debug log file or what ever else I want...
    */
}

and the fromCompiler (named anything) will be a char[] indicating the reason
from the compiler, like line number and anything else you may want to tack
on it.
May 20 2003
parent reply Ilya Minkov <midiclub 8ung.at> writes:
Usually, in a GUI application you have an event-handling loop. Inside
this, there sould be an exception handler, which would extract the
string and show the error mesage, then continue the event loop as
normal. For some exception types, you might want to override this behaviour.

As to assert, it is only for the cases which should *never* happen.
Like, "i know this function would return incorrect results if given
input==x, so i assert that (input!=x), but however, this function should
never get input==x". This is because assert is eliminated in release
build. Assert is a quick construct to isolate the bugs of a program
itself. The user should *never* see an assert.

If you want to process something that happens regularly - like file not
found, input/output error, something usual and which depends on the
environment and not on the program, take care to create and throw an
exception of a corresponding type - with a sensible error string. These
can then be handled in a stuctured manner. Please also take care to
define new exception types if you feel like it. Like, subclass
FileException into e.g. NetworkFileException - and the usual
FileException handler would catch it as well if requiered.

BTW, why don't you simply read the manual?
http://www.digitalmars.com/d/errors.html

-i.

Vathix wrote:

 Should assert() be avoided in a win32 gui app? All the user will see
 is the program terminating for no reason.. or maybe there could be a
 way to define what assert will do? like...
 
 assert(fromCompiler) { MessageBoxA(null, toStringz(fromCompiler),
 "assert!", MB_ICONERROR); /* write to debug log file or what ever
 else I want... */ }
 
 and the fromCompiler (named anything) will be a char[] indicating the
 reason from the compiler, like line number and anything else you may
 want to tack on it.
May 20 2003
parent reply "Vathix" <Vathix dprogramming.com> writes:
Well, I pretty much knew what you said and have read the manual.
Asserts shouldn't be part of the release, agreed, but sometimes the debug
application is released as a test version and the user might want to know
what went wrong in that near impossible situation..  it looks like even DMD
is in debug mode, as it is alpha.
May 20 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Vathix" <Vathix dprogramming.com> wrote in message
news:badt6u$3tp$1 digitaldaemon.com...

 Well, I pretty much knew what you said and have read the manual.
 Asserts shouldn't be part of the release, agreed, but sometimes the debug
 application is released as a test version and the user might want to know
 what went wrong in that near impossible situation..  it looks like even


DMD

 is in debug mode, as it is alpha.


What you can do is write a catch for the assertion exceptions, and throw up
a message box giving your customer instructions on how to report the bug
back to you.
May 23 2003
parent reply "Vathix" <Vathix dprogramming.com> writes:
"Walter" <walter digitalmars.com> wrote

 What you can do is write a catch for the assertion exceptions, and throw


up

 a message box giving your customer instructions on how to report the bug
 back to you.


oh! that is good.
It doesn't seem to work with my wndproc callbacks (reason why I didn't
realize you could catch it): I have try/catch(Object) in my WinMain(), and
in the doit() I have my windows message loop. I guess I have to catch in my
wndproc because it doesn't know how to find the handler in WinMain.
May 29 2003
parent "Walter" <walter digitalmars.com> writes:
"Vathix" <Vathix dprogramming.com> wrote in message
news:bb5fgk$13dg$1 digitaldaemon.com...

 It doesn't seem to work with my wndproc callbacks (reason why I didn't
 realize you could catch it): I have try/catch(Object) in my WinMain(), and
 in the doit() I have my windows message loop. I guess I have to catch in


my

 wndproc because it doesn't know how to find the handler in WinMain.


Windows is multithreaded; if the exception is thrown in one thread it cannot
be caught in another. This may be what is happening here.
May 30 2003