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.

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.

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.

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

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

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