On 17.02.2012 18:36, Jorge Aldo G. de F. Junior wrote:
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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
