FPC internal exception

[440bx]

Hello,

This applies to the current release of FPC, i.e, v3.2.2.  when compiling the following unit:

Code: Pascal  [Select][+][-]

1. {$MODESWITCH ADVANCEDRECORDS    ON}
2.  
3.  
4. unit ErrorHandler;
5.  
6.  
7. { --------------------------------------------------------------------------- }
8. INTERFACE
9. { --------------------------------------------------------------------------- }
10.  
11. type
12.   TERROR_ID =
13.   (
14.    eid_no_error,
15.  
16.    eid_uninitialized_program_data
17.   );
18.  
19. type
20.   TERROR_STATE    = record
21.     strict private
22.       es_procname_last_entered : pchar;   { name of last entered function/proc}
23.       es_error                 : TERROR_ID;
24.  
25.     public
26.       procedure Init();
27.       function  Errored()          : boolean;
28.       procedure SetError(InErrorId : TERROR_ID);
29.       procedure SetProcName(InProcName : pchar = {$I %CURRENTROUTINE%}};
30.   end;
31.  
32.  
33. var
34.   ErrorState     : TERROR_STATE;
35.  
36.  
37. { --------------------------------------------------------------------------- }
38. IMPLEMENTATION
39. { --------------------------------------------------------------------------- }
40.  
41.  
42. procedure TERROR_STATE.Init();
43. begin
44.   es_procname_last_entered := nil;
45.   es_error                 := eid_no_error;
46. end;
47.  
48.  
49. function TERROR_STATE.Errored : boolean;
50. begin
51.   result := es_error <> eid_no_error;
52. end;
53.  
54. procedure TERROR_STATE.SetError(InErrorId : TERROR_ID);
55. begin
56.   es_error := InErrorId;
57. end;
58.  
59. procedure TERROR_STATE.SetProcName(InProcName : pchar};
60. begin
61.   es_procname_last_entered := InProcName;
62. end;
63.  
64.  
65. end.

The compiler reports an internal exception:

Code: Text  [Select][+][-]

1. [size=10pt]Verbose: Compiling ErrorHandler.pas
2. ErrorHandler.pas(33,51) Error: Compilation raised exception internally
3. Verbose: Compilation aborted
4. Debug: An unhandled exception occurred at $00000001000B7860:
5. Debug: EAccessViolation: Access violation
6. Debug:   $00000001000B7860
7. Debug:   $00000001000BB450
8. Debug:   $00000001000BC0A9
9. Debug:   $00000001000BC43E
10. Debug:   $000000010015AC62
11. Debug:   $00000001000E7344
12. Debug:   $00000001000E6FDD
13. Debug:   $00000001000E8A33
14. Debug:   $00000001000EA924
15. Debug:   $00000001000EAC47
16. Debug:   $000000010017BFBE
17. Debug:   $000000010017C624
18. Debug:   $000000010017CE90
19. Debug:   $00000001001601F2
20. Debug:   $0000000100160EBD
21. Debug:   $00000001000E669E
22. Debug:   $000000010019D592
23. Debug:
24. Verbose: D:\fpcTrunk2\fpc\bin\x86_64-win64\ppcx64.exe returned an error exitcode[/size]

It does not like having the {$I %CURRENTROUTINE%} as the default value for an optional parameter.

ETA:

Just to be on the safe side, this is on Windows, specifically Windows 7, 64 bit using the 64 bit version of the FPC compiler executed by Lazarus 64bit v3.99

Anything else you want to know, just ask.

[440bx]

It's probably obvious what I was trying to accomplish.  Have the "SetProcName" automatically grab the function/procedure name of the function/procedure where it is being invoked.  It would be very convenient to make that work somehow.

So that's my question now: does anyone know a way that is acceptable to the compiler to have it feed the function/procedure name as a parameter value ?

thank you for your help.

[Martin_fr]

It also fails if the "{$I %CURRENTROUTINE%}" is placed outside the class in the interface section...

And in both cases, I would ask what should it include? There can't be a current routine, outside of a routine? (not sure if the header of a routine is considered part of it for that particular directive).

Of course, it still shouldn't crash, but rather give an error....

[Martin_fr]

Have the "SetProcName" automatically grab the function/procedure name of the function/procedure where it is being invoked. 

I was thinking about 2nd guessing that... Because (if that code worked), I would expect it to include the name of the procedure that contains the directive. So always "SetProcName".

IIRC someone did once try that with macros, and that did not work either.

[440bx]

IIRC someone did once try that with macros, and that did not work either.

That's the kind of stuff that crosses the mind while coding and tried to see if by any chance it works (don't want to miss out on a good thing if it works.)

It was worth a try... didn't work... oh well.

but, as you said, it should emit an error not an internal exception.

[Martin_fr]

Btw, depending on the underlaying needs....

If you did not plan on local debug logging, but rather something like printing traces "client side" at runtime, so people using your app can send in a (meaningful) trace for errors, then you don't need the names.

Well in most cases. If the target OS allows a non-relocating exe (Mac does not, but afaik Win and Linux do).
- Compile with debug info
- keep a copy with debug info
- create a stripped copy (must be from the same compiler run. Not just same source, but really same compilation)
- distribute the stripped copy
- use Leak-and-traces resolve button, to resolve address traces against the copy with debug info.

Test it before relaying on it.

[440bx]

Thank you Martin.

Like most everyone, I try to keep error handling as simple as possible (not always easy.) 

My preferred method so far, is to output the routine name and a number that identifies the error sequentially in the routine.  That way if the same error can occur more than once, both errors have different identifiers because one has to forcefully be before or after the other, hence have a different sequence number.

Fortunately, the program I'm currently working on is fairly simple and, doesn't require anything complicated.

Your mentioning macros gave me an idea.  The following works and comes reasonably close to what I originally wanted:

Code: Pascal  [Select][+][-]

1. {$define _Entered:=ErrorState.SetProcName({$I %CURRENTROUTINE%})}

That macro along with the error management unit works great

All I need is to code "_Entered;" upon routine entry and the name is all set. 

To set the error (if any), I've got:

Code: Pascal  [Select][+][-]

1. {$define _Errored:=ErrorState.SetError}

Prefixing the macro names with "_" also makes them stand out (and no other routine in my code is prefixed with "-", therefore that really makes the macros stand out.)

Now that I'm thinking about making the macros stand out, I might make them uppercase too.  They would be the ONLY non-type uppercase identifiers, since all the code is in lowercase, they would really stand out.

Thank you for the help and the mention of the macro... that definitely helped.

[Martin_fr]

Interesting that this macro works, because IIRC (need double checking) someone tried that with the filename/linenumber, and it added the line number where the macro was declared, rather that where it was used.
Of course there is no routine where you declare the macro (I assume...)

Personally, I use a code template

Code: Text  [Select][+][-]

1. debugln(['$ProcedureName() '|]);

The text is inserted, when I initially create the template. So it doesn't follow renames. And I can't copy and paste it.
Actually, I could just put the compiler directive there, and that would work (for me).
I don't mind, if it is longer text to read. It gets all auto inserted, so no work to type.