Ignore exception type from code

[aehimself 396]

Hello,

 

I just finished rewriting a method which now only lists font names useable by TSynEdit. The theory is easy; while enumerating Screen.Fonts I'm passing them to the exact same check as TSynEdit does (SynDWrite.pas, IsFontMonospacedAndValid). If it returns true, I add it to the list.

 

The issue is, there is a CheckOSError call in said method which break the execution of the program way too many times if it is run from the IDE. The current implementation is as follows:

function IsFontMonospacedAndValid(Font: TFont): Boolean;
var
  LogFont: TLogFont;
  DWFont: IDWriteFont;
begin
  try
    Assert(GetObject(Font.Handle, SizeOf(TLogFont), @LogFont) <> 0);
    CheckOSError(TSynDWrite.GDIInterop.CreateFontFromLOGFONT(LogFont, DWFont));
    Result := (DWFont as IDWriteFont1).IsMonospacedFont;
    if (FontFamilyName(DWFont) <> Font.Name) and (fsBold in Font.Style) then
      Font.Style := Font.Style - [fsBold];
  except
    Exit(False);
  end;
end;

I can put the EOSError exception type as a globally ignored one in Tools / Options but understandably it is not an ideal solution. I also could copy and paste this check, removing the CheckOSError but if I do I have to keep an eye on the official implementation to make sure to update my version if the original changes.

 

Is there a compiler directive which will ignore a specific exception type within a block of code?

 

Thanks!

[Steven Kamradt 20]

You could just rewrite the CheckOSError line to:

if TSynDWrite.GDIInterop.CreateFontFromLOGFONT(LogFont, DWFont) <> ERROR_SUCCESS then exit(False);

and then the exception will not be raised by the CheckOSError function wrapper.

[aehimself 396]

@Steven Kamradt An important rule of writing maintainable software is that you are not changing the code in any external components. Doing that will come to bite you in the back later on; especially if you try to update said component.

[Fr0sT.Brutal 900]

I'd suggest PR to SynEdit authors. Exception here is useless indeed.

 

[Remy Lebeau 1397]

On 7/31/2022 at 9:49 AM, aehimself said:

Is there a compiler directive which will ignore a specific exception type within a block of code?

No (plus, that would require changing and recompiling the code, in which case you may as well just take out the offending code to begin with).

 

But, you can accomplish something similar using breakpoints instead.  Put a breakpoint at the beginning of the function, go into its properties, and disable the 'Break' option, and enable the 'Ignore subsequent exceptions' option.  Then, put another breakpoint at the end of the function, go into its properties, and disable the 'Break' option, and enable the 'Handle subsequent exceptions' option.

[Steven Kamradt 20]

On 7/31/2022 at 11:51 PM, aehimself said:

@Steven Kamradt An important rule of writing maintainable software is that you are not changing the code in any external components. Doing that will come to bite you in the back later on; especially if you try to update said component.

You asked how to ignore the exception type in that block of code.  If you were using a compiler directive for a block of code you would also be making changes.

 

I would actually suggest that your rule should be more of a guideline than a rule.  If your maintaining production code, you really want your external components to also be in version control under the project they are being used in.  Otherwise, how can you possibly make sure that you are rebuilding a specific version if you have to roll back to diagnose an issue in the field? How do you insure that anyone new to the team has the exact components installed? Often I have had the need to modify a 3rd party component or source to do what I needed and it was unique enough that the vendor wasn't willing to add support for my necessary changes. In the case where its a "bypass" for debugging, you can always revert your changes once your confident that its working properly unless its something you deal with every time you debug.  Either way, if its in version control you have  a diff with the changes and its not difficult to merge some minor changes in with the next component update.

[Fr0sT.Brutal 900]

59 minutes ago, Steven Kamradt said:

I would actually suggest that your rule should be more of a guideline than a rule

It's just an experience of supporting these modified versions and keeping them up-to-date. I too have several local patches to the libs I use but sometimes applying them could be a PITA so I update these libs quite rarely. It's always better to try pushing the changes to upstream or implementing them via descendants/overriding/helpers etc

 

The issue is pretty unpleasant in fact. Exceptions are widely used for checking internal stuff so "notify on language exceptions" option becomes really unusable. Probably it's time to add a feature request to add more ignorance options - by unit name or by existence of debug info or whatever.

Edited August 5, 2022 by Fr0sT.Brutal