I am in the process or writing a interpreter for a specific task (not turing complete, just something to make easier to express something to the computer) and for the erro handling i decided to use plain old exceptions.

Code works that way :

1 - Everytime an error occurs, an exception is triggered. (Be it on my own code, or on the runtime itself, like when you cause a division by 0)
2 - There are system exceptions wich i cant control format and there are my own exceptions that are all based on TROWCOLExceptions, that has row, col and sourcefile properties to nicely describe where in the user input was the error.
3 - All code structures are wrapped around try try finally except blocks. 4 -on except blocks, a new exception (based on trowcolexception) is created from non trowcolexception, so as to make the user aware of the row and column of code related to the original exception.

something like :

procedure theobject.raiseerror(amessage : string; aprevious : exception);
var
lexcept : Trowcolexception;
Begin
lexcept := trowcolexception.create(amessage);
lexcept.row := theobject.row;
lexcept.col := theobject.col;
lexcept.source := theobject.source;
lexcept.previous := aprevious;
raise lexcept;
end;
End;

this causes all exceptions to being tagged with all row/col/sourcefile name of nested structures overlying the place where the error ocurruded, including the error row col of the offending code. something like freepascal itself does when you compile with -gl

code ends app being wrapped around thousands of try except blocks all creating new exceptions and appending the older ones to the previous property, in a kind of linked list that makes code fully traceable.

the problem is. sometimes the system inexplicably throws runtime error 202 and quits. ignoring exceptions and etc.

i debuged the problem into the raise lexcept line of raiseerror.

so i am inclined to think that exceptions arent supposed to live much longer after their corresponding try except handling block.

is that true ? actually, how are exceptions raised ? can i reraise one ?

To make things short: yes, that is true. Exceptions are freed after either a except handler has handled it without reraising or after the "unhandled exception" handler has taken control (though in the last case it could be that the exception isn't freed, because the program is simply terminated...).

An exception can be reraised by "raise;", but this won't help much in your case as you can't pass a new Exception to the reraised Exception.

Regards,
Sven

The AcquireExceptionObject function should be able to overcome this problem. It is designed to "acquire" a reference to the exception object so you sort of "own" it (actually it's reference counted; you own one refcount) and it won't be automatically freed after the except block. Be sure, then, in the destructor of Trowcolexception, to release the nested exception object.

http://www.freepascal.org/docs-html/rtl/system/acquireexceptionobject.html

http://www.freepascal.org/docs-html/rtl/system/releaseexceptionobject.html

problem. It is designed to "acquire" a reference to the exception object so you sort of "own" it (actually it's reference counted; you own one refcount) and it won't be automatically freed after the except block. Be sure, then, in the destructor of Trowcolexception, to release the nested exception object.

http://www.freepascal.org/docs-html/rtl/system/acquireexceptionobject.html http://www.freepascal.org/docs-html/rtl/system/releaseexceptionobject.html

This is one of those moments where I need to aknowledge that even I never stop learning ;)

Regards,
Sven