Thread overview
Runtime Error Reporting
Dec 03, 2003
Berin Loritsch
Dec 03, 2003
Charles Sanders
Dec 10, 2003
Walter
December 03, 2003
One of the great features of Java is that any time there is an exception
thrown that is not caught, there is a stack trace so that we can find the
offending file, method, and line where the exception occured--and sometimes
the exception occured in a third-party library so the stacktrace is essential.

The one main complaint about D error reporting at runtime is that there isn't
even a source file, class, method, line number or anything to clue me in where
the problem occured.  I just know that there was an Access Violation or
something.  While I am still mucking about with toy problems, this is not a
problem because I kinda know where things are going wrong.  However, as soon
as the complexity exceeds a certain level, I need to know more information.

Is there any way we can embed at least the class and method name, and if debug
info is compiled in the source file and line number?

December 03, 2003
Also, i have a try { assert(0); } catch ( Object o) { msg(o.toString() ); }

all i get is fatal error, is their _any_ way to add more information to whatever assert throws, ( man i dislike exceptions ).

C


"Berin Loritsch" <bloritsch@d-haven.org> wrote in message news:bqkqme$2nd3$1@digitaldaemon.com...
> One of the great features of Java is that any time there is an exception thrown that is not caught, there is a stack trace so that we can find the offending file, method, and line where the exception occured--and
sometimes
> the exception occured in a third-party library so the stacktrace is
essential.
>
> The one main complaint about D error reporting at runtime is that there
isn't
> even a source file, class, method, line number or anything to clue me in
where
> the problem occured.  I just know that there was an Access Violation or something.  While I am still mucking about with toy problems, this is not
a
> problem because I kinda know where things are going wrong.  However, as
soon
> as the complexity exceeds a certain level, I need to know more
information.
>
> Is there any way we can embed at least the class and method name, and if
debug
> info is compiled in the source file and line number?
>


December 10, 2003
"Berin Loritsch" <bloritsch@d-haven.org> wrote in message news:bqkqme$2nd3$1@digitaldaemon.com...
> One of the great features of Java is that any time there is an exception thrown that is not caught, there is a stack trace so that we can find the offending file, method, and line where the exception occured--and
sometimes
> the exception occured in a third-party library so the stacktrace is
essential.
>
> The one main complaint about D error reporting at runtime is that there
isn't
> even a source file, class, method, line number or anything to clue me in
where
> the problem occured.  I just know that there was an Access Violation or something.  While I am still mucking about with toy problems, this is not
a
> problem because I kinda know where things are going wrong.  However, as
soon
> as the complexity exceeds a certain level, I need to know more
information.
>
> Is there any way we can embed at least the class and method name, and if
debug
> info is compiled in the source file and line number?

Assertions will give the file and line number of where they were thrown. For access violations, the best way is to run the program under a debugger, which will then highlight the statement which failed.