New Rule: TryFunctions should only be used on low level functions without database operations

[finnpedersenkazes]

TryFunctions should only be used on low level functions without database operations

This is my claim. But is it true?
What do you think? Is there a reason for a new rule?

TryFunction on high level functions

When using [TryFunction] on a function that calls other functions it becomes complicated to understand where the error happend.

TryFunctions on functions with database operations

I am not sure where I picked this up, but I ether read it somewhere or someone told me.

But apparently, it should be a bad idea to have TryFunctions on functions with database operations.

Examples

Examples on how to use [TryFunctions] from My article on TryFunctions in AL

[TryFunction]
procedure TryDmy2Date(Day: Integer; Month: Integer; Year: Integer; var NewDate: Date)
begin
    NewDate := DMY2Date(Day, Month, Year);
end;

And the use of it.

procedure IsDmyValidDate(Day: Integer; Month: Integer; Year: Integer): Boolean
var
    NewDate: Date;
begin
    exit(TryDmy2Date(Day, Month, Year, NewDate))
end;

procedure Dmy2DateWithDefault(Day: Integer; Month: Integer; Year: Integer; DefaultDate: Date) NewDate: Date
begin
    if not TryDmy2Date(Day, Month, Year, NewDate) then
        NewDate := DefaultDate;
end;

[finnpedersenkazes]

https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-handling-errors-using-try-methods?utm_source=chatgpt.com

[finnpedersenkazes]

https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/attributes/devenv-tryfunction-attribute

[Arthurvdv]

I remember that we hade same idea in the BusinessCentral.LinterCop repo on Write transaction in the scope of a TryFunction

The consensus back then was:

I believe that if the rule were limited to the method itself, it could give a false sense of security. If I could somehow manage to traverse the whole tree of chained methods inside the extension itself, then I’m afraid I’d still get stuck on extension dependencies and/or dependency injection through interfaces.

Now almost 2 year later, I no longer see “traversing the whole tree of chained methods” as an issue anymore. But I still believe the “false sense of security” risk is still there. Even if we can traverse the call tree within an extension, there probably will boundaries we cannot reliably cross, like extension dependencies, interfaces, injected implementations, etc.

So now could be the time to revisit this with a fresh pair of eyes. How should the rule should look like? I’d love to hear ideas from the BC community on this 🤗