Thread overview | |||||
---|---|---|---|---|---|
|
December 03, 2003 Runtime Error Reporting | ||||
---|---|---|---|---|
| ||||
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 Re: Runtime Error Reporting | ||||
---|---|---|---|---|
| ||||
Posted in reply to Berin Loritsch | 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 Re: Runtime Error Reporting | ||||
---|---|---|---|---|
| ||||
Posted in reply to Berin Loritsch | "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. |
Copyright © 1999-2021 by the D Language Foundation