Stack overflow

Regan Heath regan at netmail.co.nz
Fri Jun 22 09:56:22 PDT 2012


On Fri, 22 Jun 2012 15:55:12 +0100, Namespace <rswhite4 at googlemail.com>  
wrote:

> If you have a null object you get an Access Violation without _any_  
> further information. That totally sucks.

It doesn't have to be that way.

A debug executable contains all sort of debugging information and a Just  
In Time debugger can attach and make use of it to show the cause of the  
access violation.  Further, on both windows and various flavours of unix  
you can get a stack dump, which can be loaded into a debugger and used to  
locate the access violation.

For the JIT case it's all automated on windows if/when you have visual  
studio installed, as soon as any application crashes a dialog appears and  
you can attach/debug.

For the stack trace case I prefer using WinDbg where you can load the  
stack trace, point it at the PDB (produced even on a release build) and  
figure out where it crashed.  If you have no PDB you can use a MAP file  
and the stack offsets to determine the crash location.

Alternately, on windows you can call SetUnhandledExceptionFilter() to  
install a handler to catch any/all unhandled "exceptions" including access  
violations etc and then using the EXCEPTION_POINTERS ContextRecord member,  
walk the stack and produce your own stack trace at the instant the  
application "crashes" - I have some code which does this somewhere..

This last idea could automatically be built into exes produced by DMD so  
they all crash and output a stack trace (perhaps only if built in debug  
mode) and something similar can surely be done for unix.  It's been a  
while since I did any serious development in D so maybe automatic stack  
traces already happen for some platforms?

> And in my opinion a small "Ref!Type" is more informative for others who  
> use your code and you do not have to write assert(obj !is null); any  
> time in any method again.

It is nice to perform the assert/check once, then know from that point on  
it cannot be null ever again - saves multiple asserts/checks and makes the  
code cleaner in terms of having less "noise".  I think types which cannot  
be null are useful for that reason.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/


More information about the Digitalmars-d-learn mailing list