Watch, Follow, &
Connect with Us
Public Report
Report From: Delphi-BCB/RTL/Delphi/RTL Exceptions    [ Add a report in this area ]  
Report #:  1549   Status: Open
Exception tracking to source
Project:  Delphi Build #:  6.0.6.240
Version:    7.0 Submitted By:   Kristofer Skaug
Report Type:  New Feature Request Date Reported:  6/18/2002 6:34:45 AM
Severity:    Commonly encountered problem Last Updated: 3/20/2012 2:24:39 AM
Platform:    All platforms Internal Tracking #:   193323
Resolution: None (Resolution Comments) Resolved in Build: : None
Duplicate of:  None
Voting and Rating
Overall Rating: (28 Total Ratings)
4.50 out of 5
Total Votes: 14
Description
It would be nice if Delphi provided the tools for reporting the line of code where an exception was raised. This for example by expanding the Exception base class with a SourceRef string (unit and lineref) that could be inspected in the exception handler.

Also a stack trace would be a desirable output (David Marcus), accessible as an (optional) 2nd info string (or better yet, a string list!).

Currently JCLdebug provides some such an add-on capacity but I would prefer it to be native to Delphi/RTL.
Steps to Reproduce:
None
Workarounds
None
Attachment
None
Comments

Radek Jedrasiak at 6/19/2002 5:05:52 AM -
This is a *must have* 'out of the box' functionality.

1.) This helps the developers from the very first moment Delphi is used,
during development

2.) This helps developers after the release to localize the place an exception
is raised, thus helping them to react faster to exceptions reported by the users

the default exception handler of the vcl, rtl ...whatever should provide
the info needed to localize the point an exception is raised.

David Marcus at 6/30/2002 4:40:46 PM -
Line number and stack trace, please. Exceptional Magic is shareware that provides this, but it should definitely be part of Delphi.

Kristofer Skaug at 7/1/2002 12:20:28 AM -
Added stack trace option to request.

Joe White at 7/1/2002 12:31:42 PM -
Note that JCL's stack trace usually doesn't match the IDE's - the JCL either misses some items, or adds extra ones (depending on whether you enable raw stack tracking).  So yes, I'd like to see Delphi provide this info.

Obviously, you would need to distribute a map file or some sort of debug info with your app.  I like JCL's tactic of including this info as a resource in the compiled EXE.

Radek Jedrasiak at 7/15/2002 3:07:24 PM -
This ofcourse should also provide information about the package/dll
an exception was raised.

Without MAP file provided only addresses could be listed. Once
an MAP file is provided the addresses could be resolved to files/linenumbers
or even better file-class-method-linenumber

Radek

Kristofer Skaug at 8/1/2002 3:16:54 AM -
Not sure you need a map file necessarily.
EAssertionFailure does report source file and line number, without using map file.
So why couldn't other exceptions do the same?

Wolfgang Junker at 8/1/2002 6:07:18 AM -
IMHO, you have two options: either provide a map file or write the mapping into the compiled file, which is what obviously happens for asserts (as I guess from reading (and partially understanding) the system.pas source). Doing that for everything would significantly increase the size of compiled files.

I think a map file is the better solution, as you can supply it only when necessary. The exeption handling subsystem should then be able to autodetect the presence of the map file and change the exeption dialog accordingly.

Kristofer Skaug at 8/23/2002 7:30:50 AM -
sure, that's better than nothing!

Peter Morris at 8/5/2002 3:55:37 AM -
When I get runtime errors on app close, it would also be nice to know where they occur, and have a textual description too instead of a runtime number.

Kristofer Skaug at 8/23/2002 7:32:04 AM -
Not sure what you mean by this. Is exception reporting different during app start/close?

Wiebe Tijsma at 5/7/2005 4:06:43 AM -
Yes, it's currently near to impossible to trace where an application closing error (for example accidently freeing an object that's inherited from TInterfacedObject in finalization) comes from (runtime error 217). The JCLDebug libaries can't catch them either.

Server Response from: ETNACODE01