Recent

Author Topic: fgl.EListError confusion  (Read 1940 times)

alpine

  • Hero Member
  • *****
  • Posts: 1032
fgl.EListError confusion
« on: July 14, 2021, 10:34:36 pm »
In the following example, the program calls the procedure Meow which in turn raises an exception by accessing fgl.TFPGMap<>.KeyData[] with a nonexistent key:

Code: Pascal  [Select][+][-]
  1. program Project1;
  2.  
  3. uses
  4.   Classes, SysUtils,
  5.   //fgl, //<--- comment/uncomment
  6.   unit1;
  7.  
  8. begin
  9.   try
  10.     Meow;
  11.   except
  12.     on E: EListError do WriteLn('on EListError: ', E.ClassName);  // when uncommented
  13.     on E: Exception do WriteLn('on Exception: ', E.ClassName); // when commented
  14.   end;
  15. end.
  16.  
  17.  
  18. unit Unit1;
  19.  
  20. {$mode objfpc}{$H+}
  21.  
  22. interface
  23.  
  24. uses
  25.   Classes, SysUtils, fgl;
  26.  
  27. procedure Meow;
  28.  
  29. implementation
  30.  
  31. procedure Meow;
  32. begin
  33.   with (specialize TFPGMap<Integer, Integer>.Create) do
  34.     if KeyData[666] = 0 then ;
  35. end;
  36.  
  37. end.

The problem is when the fgl unit is not used into the main program, then the exception handler for Excepton is activated. When fgl is used, then EListError handler is activated, i.e. forgetting to use fgl (which should not be mandatory) makes the dedicated EListError handler to miss!


Lazarus 2.0.12 r64642 FPC 3.2.2 i386-win32-win32/win64
"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

PascalDragon

  • Hero Member
  • *****
  • Posts: 5444
  • Compiler Developer
Re: fgl.EListError confusion
« Reply #1 on: July 15, 2021, 09:19:43 am »
The problem is when the fgl unit is not used into the main program, then the exception handler for Excepton is activated. When fgl is used, then EListError handler is activated, i.e. forgetting to use fgl (which should not be mandatory) makes the dedicated EListError handler to miss!

There are two EListError, one in Classes and one in fgl which are incompatible to each other. So if something raises a fgl.EListError you can't catch it with a Classes.EListError (which you do if comment the use of the fgl unit).

alpine

  • Hero Member
  • *****
  • Posts: 1032
Re: fgl.EListError confusion
« Reply #2 on: July 15, 2021, 11:17:06 am »
There are two EListError, one in Classes and one in fgl which are incompatible to each other. So if something raises a fgl.EListError you can't catch it with a Classes.EListError (which you do if comment the use of the fgl unit).
On top of that, the debugger says in both cases 'raised exception class EListError with message... [Break][Continue]', i.e. no scope/unit qualification, contributing to my confusion.

It was quite annoying. Yesterday, I've chased it about an hour, at some point even started to mistrust the FPC SEH! Accidentally, pressing Alt-Up at the right place, I've found it has a second definition. I couldn't imagine that the reason could be so simple. It is a kind of silent trap.

IMHO the exception in fgl must be renamed. Thus, it will require fgl to be used in units with exception handlers. The problem I see is with the existing sources that catch the current fgl.EListError - they will stop catching in turn.   
"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

 

TinyPortal © 2005-2018