Recent

Author Topic: Enable exceptions (extended error messages)  (Read 797 times)

noszone

  • New Member
  • *
  • Posts: 27
Enable exceptions (extended error messages)
« on: September 20, 2021, 06:32:38 am »
I am trying to enable this mode, as per manual:

https://wiki.freepascal.org/Exceptions

Quote
By default exceptions are disabled. You can opt in by using the ObjFPC or DELPHI Compiler Mode, or adding -Sx to the compiler commandline.

So my question is, where exactly to enable this -Sx or {$mode objfpc} in code? I expecting to not to see anymore errors like SIGSEV, but more informative text as indicated in the manual:

Quote
Processor-level interrupts like SIGSEGV or SIGFPU, which normally translate to run-time errors, are also changed to exceptions. For example, run-time error 200 (division by zero) becomes EDivByZero or EZeroDivide, while run-time error 216 (a general protection fault) becomes EAccessViolation.

My main goal is to see errors with extended text, if there is other ways, please advise.

PascalDragon

  • Hero Member
  • *****
  • Posts: 3384
  • Compiler Developer
Re: Enable exceptions (extended error messages)
« Reply #1 on: September 20, 2021, 09:08:33 am »
I am trying to enable this mode, as per manual:

https://wiki.freepascal.org/Exceptions

Quote
By default exceptions are disabled. You can opt in by using the ObjFPC or DELPHI Compiler Mode, or adding -Sx to the compiler commandline.

So my question is, where exactly to enable this -Sx or {$mode objfpc} in code?

Adding -Sx is misleading as that will be reset upon a $mode directive. So it's better to use $mode objfpc or $mode delphi inside your units and your program file. This directive is best placed in front of the uses-clause as the templates provided by Lazarus generate.

I expecting to not to see anymore errors like SIGSEV, but more informative text as indicated in the manual:

Quote
Processor-level interrupts like SIGSEGV or SIGFPU, which normally translate to run-time errors, are also changed to exceptions. For example, run-time error 200 (division by zero) becomes EDivByZero or EZeroDivide, while run-time error 216 (a general protection fault) becomes EAccessViolation.

My main goal is to see errors with extended text, if there is other ways, please advise.

The mode directive (or the command line parameter) only enables the raise keyword as well as the tryexcept and tryfinally blocks. To really catch exceptions you need to use the SysUtils unit at least once in your program so that the hooks that convert runtime errors to sub classes of Exception (which is declared in SysUtils as well) are set up correctly.

noszone

  • New Member
  • *
  • Posts: 27
Re: Enable exceptions (extended error messages)
« Reply #2 on: September 21, 2021, 02:02:23 pm »
Thank you very much for explanation, my current mode is {$mode objfpc}{$H+}.

Quote
To really catch exceptions you need to use the SysUtils unit at least once in your program so that the hooks that convert runtime errors to sub classes of Exception (which is declared in SysUtils as well) are set up correctly.

Could you please give an advice about SysUtils? What means use at least once. Curently I can catch EPQDatabaseError, Exception, but what to do with SIGSEGV? Or it's some general case?

PascalDragon

  • Hero Member
  • *****
  • Posts: 3384
  • Compiler Developer
Re: Enable exceptions (extended error messages)
« Reply #3 on: September 22, 2021, 09:01:45 am »
Could you please give an advice about SysUtils? What means use at least once. Curently I can catch EPQDatabaseError, Exception, but what to do with SIGSEGV? Or it's some general case?

You need to have the SysUtils unit in at least one of your program's units. If your program only consists of the main program file then you need to have SysUtils in the uses-clause of that file. And a SIGSEGV should be translated to a EAccessViolation, but if you catch Exception that should be caught as well, because EAccessViolation is a descendant of Exception. If it's not caught in your case it might be due to a debugger.

noszone

  • New Member
  • *
  • Posts: 27
Re: Enable exceptions (extended error messages)
« Reply #4 on: September 22, 2021, 09:36:33 am »
Quote
And a SIGSEGV should be translated to a EAccessViolation

How can I translate EAccessViolation into something readable automatically/manually? It's clear that I can catch some special errors like EPQDatabaseError, if I will use them in code. So the main goal to get somehing more meaningful instead of for exapmle - An unhandled exception occurred at $02D77993:
EAccessViolation (automatically, with no use of special codes like EPQDatabaseError);

PascalDragon

  • Hero Member
  • *****
  • Posts: 3384
  • Compiler Developer
Re: Enable exceptions (extended error messages)
« Reply #5 on: September 22, 2021, 01:33:52 pm »
Quote
And a SIGSEGV should be translated to a EAccessViolation

How can I translate EAccessViolation into something readable automatically/manually? It's clear that I can catch some special errors like EPQDatabaseError, if I will use them in code. So the main goal to get somehing more meaningful instead of for exapmle - An unhandled exception occurred at $02D77993:
EAccessViolation (automatically, with no use of special codes like EPQDatabaseError);

What do you mean as "something more meaningful"? Do you mean location of the code that triggered the exception? Then you should make sure that your application is compiled with debug information and use DumpExceptionBackTrace (it takes a TextFile argument, but you can use e.g. the StreamIO to initialize a text file backed by a TStream). Without debug information there simply is nothing more meaningful than the address.

noszone

  • New Member
  • *
  • Posts: 27
Re: Enable exceptions (extended error messages)
« Reply #6 on: September 23, 2021, 05:14:29 am »
Thank you, I will practice more on the subject.

 

TinyPortal © 2005-2018