Write transaction in the scope of a TryFunction

[rvanbekkum]

Starting a write-transaction in the scope of a procedure that is marked with the TryFunction attribute is not allowed when DisableWriteInsideTryFunction is set to true (for BC online it is set to true, for BC on-premise it is set to false which is the recommended value, but that's a different discussion).

It would be good if a diagnostic could be raised if there is a write-transaction in the scope of a TryFunction inside the code of the extension itself. That would be in the procedure itself and in any procedures that are invoked by the TryFunction that are contained in the same extension. If the TryFunction invokes procedures from other apps/extensions, then I don't think it can be checked whether there are any write transactions in the procedures of the other apps/extensions.
However, I think it still would be very useful to at least have a check that checks it this far (the code within the same extension).

Examples of procedures that are not allowed inside the scope of a TryFunction:

• Rec.Insert
• Rec.Modify
• Rec.Rename
• Rec.Delete
• IsolatedStorage.Set
• IsolatedStorage.Delete

And probably some others that I have missed.

[jwikman]

This is already discussed in #539

I totally understand why you didn't find that before posting this suggestion. 😅

It was closed with this comment from @Arthurvdv:

During TechDays in Antwerp we've discussed to close this PR. The main reason is that this is a complex rule to find all the references and walk though every chained method/procedure to find if there's somewhere a TryFunction in between. With the use of interfaces and/or public methods with dependency extensions, this will even be close to impossible to have a solid rule.

But I agree with you, IF it was possible to create such a rule, it would be really nice.

[Arthurvdv]

Jep, as @jwikman also has quoted here, the problem is chained methods/procedures.

I believe if the rule would limited to only 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'm going to be stuck on extension depedencies and/or dependency injection with interfaces.

Maybe this is the right example where we're hitting the limits of static code analyzers and this is the part when automated tests take over?