Try - except - finally generates no debug-breakpoint in Exception scope

[Rollo62 536]

Hi there,

 

maybe its already too late, too tired today, but I just asking myself why the code doesn't create any "blue" breakpoints steps in the Except scope anymore ?

All the other function shows debug breakpoints, and I also can debug them, only if an exception occurs, this is NOT catched here.

(running under Macos Catalina).

 

I'm just testing with the new Rx10.4.2, but I need a rest now, so maybe someone can spot the issue ?

 

function TConnector.IsDeviceConnected : Boolean;
var
    LTxt: String;
begin

    try
        try

            if Assigned( FDevSelected ) then   //<== for exapmple, here I see the "blue" breakpointe, and can debug
            begin
                if FConnection_Last.IsConnected then  //<== this mayb rais an exception, but I cannot debug it in try - except scope
                    Result := True
                else
                    Result := False;
            end
            else
            begin
                Result := False;
            end;

        except
            on E : Exception do
            begin
                LTxt   := E.Message; //<== the whole function has "blue" breakpoint steps, only these 3 lines not
                S4Debug_Step;        //<== this is just an emprty function all as nop() replacemnt

                Result := False;     //<== Nope, no breakpoints either
            end;

        end;

    finally
        S4Debug_Step;
    end;
end;

 

Edited February 27, 2021 by Rollo62

[Guest]

5 hours ago, Rollo62 said:

All the other function shows debug breakpoints, and I also can debug them, only if an exception occurs, this is NOT catched here.

if the DEBUG dont catch it, can be a new "bug" or some inconsistence of your code! it's hard to say, i'm sorry.... "Chicago" ->> big band! I love this song!

try my sample more simple:

function TConnector.IsDeviceConnected: boolean;
begin
  result := false; // by deafult always will be "false"! -> Always define a value initial and dont worry about any error below this line!!!
  //
  // I dont like use "Assigned( valueX )", sometimes it dont reflect the true necessary!!!
  //
  try
    if not(FConnection_Last = nil) and FConnection_Last.IsConnected then
      result := True;
  except
    on E: Exception do
      // what you need to do here?
      ShowMessage('my error:'+sLineBreak+ E.Message);
  end
end;

 

NOTE by Embarcadero Help System:

Quote

System.Assigned

Note: Assigned cannot detect a dangling pointer--that is, one that is not nil, but that no longer points to valid data. For example, in the code example for Assigned (SystemAssigned), Assigned does not detect that P is not valid.

procedure TForm1.Button1Click(Sender: TObject);
var P: Pointer;
begin
  P := nil;
 //
  if Assigned (P) then
    MessageDlg('You won''t see this', mtInformation, [mbOK], 0);
  //
  GetMem(P, 1024);	{P valid}
  //
  FreeMem(P, 1024);	{P no longer valid and still not nil} //  After calling this procedure, the value of the P parameter is undefined. 
  // possible solution:
   P:=nil; // again because we are on scope this block!
  //
  if Assigned (P) then
    MessageDlg('You''ll DONT see this', mtInformation, [mbOK], 0);
end;

Quote

Notes:

• FreeMem is not available in C++. In C++ you can use FreeMemory.
• If a pointer to unallocated memory is passed to FreeMem, the behavior of the application largely depends on the target platform, as follows:
  • For Windows platforms, an EInvalidPointer is raised in applications using System.SysUtils, and a run-time error is produced for applications that do not use System.SysUtils. (FastMM, the default memory manager, can detect an invalid pointer.)
  • For OS X and iOS platforms, FreeMem does not raise an EInvalidPointer exception if an invalid pointer is passed to Dispose.

 

 

hug

Edited February 28, 2021 by Guest

[Rollo62 536]

@emailx45

Thanks for your proposals, but I already checked before without the try .... finally scope, that makes no difference.

 

But your consideration to change Assigned is maybe something in the right direction.

The variable is and Object, no Pointer, so it should work as-is too IMHO.

I will check again tomorrow.

 

The whole try ... except shall catch dangling pointers, and I would expect to land in the exception scope, no matter what, or am I wrong ?

If an exception raises, then it should be catched, no matter if nil or dangling ?

 

Or are there different kinds of exception ?

Again, I should note that I'm testing on Macos/Catalina, and the Macos apps have these kind of "deadly" exceptions: "Project Xyz raised exception class SIGABRT (6)"

maybe they were handled differently than normal Delphi exceptions ?

Maybe that is an explanation too, I have to check deeper next week.

 

 

 

Edited February 28, 2021 by Rollo62

[David Heffernan 2345]

1 hour ago, Rollo62 said:

The whole try ... except shall catch dangling pointers, and I would expect to land in the exception scope, no matter what, or am I wrong ?

Yeah, you are wrong. Dereferencing an invalid pointer could result in anything. Exception. Code apparently working. Or anything else really. 

[Hans J. Ellingsgaard 21]

Could it be this problem you have run into?

 

https://www.ideasawakened.com/post/rad-studio-10-4-2-is-now-available-with-possible-cure-for-the-blue-dot-problem

[Rollo62 536]

41 minutes ago, David Heffernan said:

Yeah, you are wrong. Dereferencing an invalid pointer could result in anything. Exception. Code apparently working. Or anything else really. 

Yes, but I can see an exception in the IDE.

I thought as long as I can see it, the compiler should be able to capture it.

 

16 minutes ago, Hans J. Ellingsgaard said:

Could it be this problem you have run into?

I think thats not the issue, I have doublechecked the settings, they should AutoSave to CrLf, and the line endings are OK.

Moreover, I have no "misaligned" "blue dots", but only "green lines" instead of them in the except scope.

 

I can follow Davids argument about anything goes, but shouldn't the compiler generate "blue dots" as debug steps anyway ?

At that time there is no exception yet, but still I have no debug breakpoints.

It looks like completely "dead" code, never compiled to binary:

 

also nil doesn't make much difference

 

 

 

Edited February 28, 2021 by Rollo62

[David Heffernan 2345]

13 minutes ago, Rollo62 said:

Yes, but I can see an exception in the IDE.

I thought as long as I can see it, the compiler should be able to capture it.

Correct that the debugger should capture it (note it's the debugger not the compiler, the compiler runs before your program).

 

My point is an aside, merely that you must not assume that dereferencing an invalid pointer will lead to an exception. That's a common misconception. I've no idea about the debugger issue you face. 

Edited February 28, 2021 by David Heffernan

[Rollo62 536]

Right, but it looks as if the compiler doesn't produce any except code here.

Of course this is only blue/green colors, not code, but I assume that compiler didn't generate anything here.

I have to check deeper, since I never have seen that behaviour before.

Maybe there is some strange condition that refuses to compile except code ?

Edited February 28, 2021 by Rollo62

[David Heffernan 2345]

1 minute ago, Rollo62 said:

Right, but it looks as if the compiler doesn't produce any except code here.

You mean that the code is not compiled and so never runs? Or that the debugger cannot break here. The fact that you seem to confuse the debugger and the compiler isn't helping. 

[Pat Foley 51]

Maybe a build all projects will surface them

[Daniel 417]

1 hour ago, David Heffernan said:

The fact that you seem to confuse the debugger and the compiler isn't helping. 

Maybe - but this harsh nitpicking is not helpful either. There are so many ways to find the right words - sometimes I wish you'd find a more relaxed wording...

[Attila Kovacs 629]

I'm wondering if it has something to do with the try/except/finally tweak introduced in the new compiler and the debugger is lacking behind?

[David Heffernan 2345]

1 hour ago, Daniel said:

Maybe - but this harsh nitpicking is not helpful either. There are so many ways to find the right words - sometimes I wish you'd find a more relaxed wording...

Doesn't seem like nitpicking here. It seems like it actually matters whether the issue is that the compiler has generated the code, or that the debugger won't break on it. Both seem to have been called in to question. As somebody who tries to solve problems, I know that clear terminology makes it possible to clearly specify and describe the problem. 

[Daniel 417]

This is true without any doubt. And I totally agree on the value of clear terminology - my criticism was not about the technical parts of your posts. I am sure you know that.

[Vandrovnik 214]

Can you create a reproducible small example? I have tried similar code and blue dots are present and debugger stops on them on breakpoint.

[Rollo62 536]

@Daniel

Thanks for your intervention, but don't worry.

The fact that David thinks I'm confusing the debugger and/or the compiler doesn't offend me much.

At least this is my daily work

 

I just made a fast test, introducing a forced raise before the part in question, et voila: All looks OK.

So the question is who is confused most; the compiler, the debugger or myself.

 

 

I will try to reproduce that in a smaller code, but I'm afraid that this doens't work.

Maybe I find time to check that tomorrow.