[fpc-devel] Const optimization is a serious bug

Den Jean Den.Jean at telenet.be
Fri Jul 8 19:59:54 CEST 2011


On Friday 08 July 2011 12:05:02 Jonas Maebe wrote:
> The main problem here is that FPC's exception handling is based on  
> setjump/longjump. This technique has a relatively high overhead for  
> "try", but low overhead when an exception actually occurs (of course,  
> since exceptions are supposed to happen only exceptionally, that's not  
> a really good selling point). The main reason we use it is because  
> it's easy to implement.
> 
> A better approach would be to use SEH-based exception handling (which  
> has no overhead at all for "try", and a high overhead in case an  
> exception occurs), but that woud require
I strongly prefer the current situation where the occurrence of 
exceptions does not incur an important extra overhead compared to
the nominal situation.

In the type of applications I write (Air Traffic Control Radar Screens,
Electronic Strips and System Interfaces) it is considered good practice 
to catch exceptions in every procedure because it is a must that 
the applications always survive and continue to provide the remaining,
not affected services.(graceful degradation principle)

I do not want any discussions whether catching exceptions is good or not.
If someone thinks otherwise, I do not care at all, do not bother me or 
this mailing list. 

However what is imperative is that when many exceptions occur, there should 
not be a mayor performance penalty. One of the reasons I use languages such 
Pascal and Ada for this type of applications, is that they are very fast, 
(though I also have foreseen code to shutdown services with too many problems 
in a given time frame). So I beg you to leave exceptions as is (please :-)). 

kind regards,

Den Jean



More information about the fpc-devel mailing list