• Berin Loritsch (12/12) Dec 03 2003 One of the great features of Java is that any time there is an exception
• Charles Sanders (14/26) Dec 03 2003 Also, i have a try { assert(0); } catch ( Object o) { msg(o.toString() )...
• Walter (13/25) Dec 09 2003 sometimes

Berin Loritsch <bloritsch d-haven.org> writes:

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?

"Charles Sanders" <sanders-consulting comcast.net> writes:

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?

"Walter" <walter digitalmars.com> writes:

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