On 13/02/2013 16:50, Giuliano Colla wrote: > IMHO the try..except..finally construct should provide exactly the same > functionality as a nested > try > try > [code] > except > [code] > end; > finally > [code] > end; > > i.e. it should be executed whatever happened in the sections between try and > finally (except if somewhere there was an Application.terminate!). Any > exception not handled shoud be re-raised after the finally block has been > executed. > The advantage would be to get rid of one level of nesting, making the code > more readable and less error prone. > This would guarantee both proper error handling and freeing of global > resources, even in presence of errors. >
> Giuliano > It is subtle, I agree, but in try try [code] finally [code] end; except [code] end; (my version) I can catch the errors of either normal and finally code; I assume that try...finally...end is the more important; it is try...finally.. end that has to go without errors, or else one will be reported; if no exception happens, except is omitted; the except section in this case, can catch anything and its job is to decide whether to allow further execution, show/log a message or bail out. (also AFAICS this way it is recommended to be used in most snippets) In your case (try..finally...end being the outer), what if it may not be possible to free the global resources (e.g. if you .Created a TStringList, and in finally you want to .Free it, but say, its pointer got corrupted or something free'd it already, and you can't - you'll get an AV which you'd have to catch in another try..except..end to properly show user a message? Or if something else that has to be done in finally section, throws?) Kind Regards, Lukasz _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
