Uncaught .Get() - Info

[JeremyVyska]

Many times a .Get(), you WANT the program to halt, so you don't catch the error and let the platform deal with it.

But, I know a LOT of my insidious bugs I've run into over the years have just been .Get() calls where the passed param wasn't right. the .Get() failure by the platform doesn't adhere to the newer way of elevating to the user what they can do about the situation.

Could it be an idea to watch for .Get() calls that aren't wrapped with if .Get() then handling (etc)?

I'm also thinking this is potentially annoying, so my thinking was an Info level only to start.

[StefanMaron]

I am not sure I fully understand your idea. Are you talking about validating that the parameters passed into .Get() match the PKs of the table you are calling it on?

[Arthurvdv]

If I understand correctly, the rule should validate if the return value (boolean) is used from the .Get method.

Customer.Get(MyCustomerNumber); // Raise a warning that the return value is not used

// Do not raise a diagnostic on the case below
if not Customer.Get(MyCustomerNumber) then
   Error('Could not retrieve the customer');

I would suggest that next to the if statement, also other operators could be applied, like;

case Customer.Get(MyCustomerNumber) of
   true: // My Logic
end;

Found := Customer.Get(MyCustomerNumber);

A generic approach could be have the rule focus on the unused return value (boolean) of the method.

I think it’s a great rule and would also include other operators, like for example .Find and .FindSet. I tend to do this on database readings operations, but on a .Insert, .Modify or .Delete I mostly don’t have a if-statement around this, so I’m unsure what to do with those.

[christophstuber]

Personally I'm hesitant about using the return value of write operations. It forces the write to be performed immediately into the database and not use any buffering https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/optimize-sql-bulk-inserts.

[Arthurvdv]

Good call @christophstuber, I've forgot about this.
If I did understand @JeremyVyska right, then the rule should indeed be limited to read operations only to prevent this.

[JeremyVyska]

Yep. It's up to a Dev to decide for their app if the 'Record 'bleh' was not found' is OK for them to emit to the user, but for me, I'd like to enforce better error handling on failed .Get() calls. Having a rule for it lets me elevate the severity for my projects.

[JeremyVyska]

Just to give a better code sample.

Customer.Get('FUBAR');

This will throw an error in most BC systems I hope, but nothing in VSC cares about it (other than the literal). However, from a UX side, if something is wrong there, it gives no opportunity for a user to 'do anything' other than try to interpret the base command.

I'd like the rule to notice that call so I can then require more code like

DummyVar := 'FUBAR';
if Customer.Get(DummyVar) then begin
...
end else
  EmitErrorInfo(CustomerNotFound,DummyVar);

And my emit error info could be a collectible or maybe an error with a Custom Action, etc. Something to encourage 'help the user out'.