function and result

[440bx]

Let's repeat, slowly:

yes, good idea, make that very, very slowly.  A function that suffers an exception - in your last piece of code, one that it doesn't even recover from -  cannot return a value indicating it was successful.   This really shouldn't be difficult to grasp.

IOW, exceptions are not indicators of successful execution.    Slower than that and, soon continental drift will be considered fast.

[lucamar]

<sight> Yeah, whatever you say. Bye.

[jamie]

There may be a race condition between FileExists and LoadFromFile, so...

Code: [Select]

function TEvarilBuffClass.is_PNSN_already_inserted(const FileName, PNSN : string) : boolean;
var
        i    : integer;
        List : TStringList;
begin
List := TStringList.Create;
try
        try
                List.LoadFromFile(OutputFile);
                for i := 0 to (List.Count - 1) do  if (AnsiPos(PNSN, List.Strings[i]) > 0) then begin
                        WriteToMemoParent(PNSN + ' already inserted');
                        exit(True);
                end;
                exit(False);
        except
                exit(False);
        end;
finally
        List.Free;
end;
end;

My comments about the leaks were the fact that you EXIT all over the place but you never free the List you created.

[Zoran]

My comments about the leaks were the fact that you EXIT all over the place but you never free the List you created.

He does in finally block.
Finally block is executed, even after Exit. See the example at the bottom of this page.

[jamie]

That behavior must be different than my old Delphi cause using EXIT in my D3 would simply Exit the procedure and that's it, it would not jump to the
Finally section Unless there were some bug in Delphi, who knows

[creaothceann]

using EXIT in my D3 would simply Exit the procedure and that's it, it would not jump to the Finally section

Maybe you used exit outside of a try block.

[ASerge]

A function that suffers an exception - in your last piece of code, one that it doesn't even recover from -  cannot return a value indicating it was successful.

Because in this case the function does not return control to the call point, and that there was set as result is meaningless.

[jamie]

This EXIT feature had to come out some time after my D3, I just tested it and it does not jump to the finally section, it simply exits the
procedure.
  I do have D7 installed on a laptop, I guess I could test that one...
 
anyways it's no biggie, thanks.

[440bx]

A function that suffers an exception - in your last piece of code, one that it doesn't even recover from -  cannot return a value indicating it was successful.

Because in this case the function does not return control to the call point, and that there was set as result is meaningless.

I agree that the result is meaningless in that case.  My point is simply that in a well written program no function would return a value indicating that it executed successfully when it actually didn't.  Anything else, just isn't "clean".   It's just not good programming.

[lucamar]

And ASerge's and my point is that setting the result and returning the result are different things. Setting the result as soon as you know it is good programming, whether a later exception will prevent returning it or not.

Of course it is better, as I said above, to try to avoid the possibility of that later exception--which may or may not be easily done. Since the OP used that call to WriteToMemoParent() in his code one would assume he prefers to do it that way, so I followed his lead. Which is good forum etiquette.

As it is also good etiquette not to stay off-topic for too long, this is my last post about this. Ciao!

[440bx]

Setting the result as soon as you know it is good programming, whether a later exception will prevent returning it or not.

You don't know the result of a function until the function returns _normally_.  Unless a function executes successfully - which includes not exiting through an exception - it shouldn't be setting a result indicating that it executed successfully since it obviously didn't.

Of course it is better, as I said above, to try to avoid the possibility of that later exception--which may or may not be easily done.

Apparently some people (no idea who they are, of course) have difficulties writing decent code.  If writing good code is too difficult for someone then they should probably be doing something else - hopefully something they have some talent for, which makes it relatively easy for them to do it right.

Which is good forum etiquette.

At least you're concerned about good forum etiquette.  Add concern for good code to that and you're all set.

As it is also good etiquette not to stay off-topic for too long, this is my last post about this. Ciao!

That is good news.  Hopefully this time it will actually be that way.

Additionally, it seems you didn't notice that I replied to Serge, not to you.

Ciao (hopefully.)

[creaothceann]

This EXIT feature had to come out some time after my D3, I just tested it and it does not jump to the finally section, it simply exits the
procedure.

Works as expected.

[jamie]

Lets clarify this, it works as YOU expected, not me, cause it does not work that way with my old Delphi nor is the EXIT procedure even
documented to work that way, it clearly states that it exits the procedure or function, not any block boundaries.

[Thaddy]

Exit() in FreePascal was first. (Not Exit without parameters) Delphi added it later. E.g. D7 doesn't even know that syntax.
It would help if some people have at least a minute grasp of such things. Probably too young.
Well, putting things in perspective has always been an old man's job.,,,

[lucamar]

[...] it does not work that way with my old Delphi [...]

IIRC (it's quite some time ago) it was considered a bug and it was corrected in Delphi 3.02. There was also a correction--again IIRC--in the try..finally section of the Language Guide. So it's possible that you both are right, depending on your respective (sub)versions.