Uncaught error

[luciano_f]

See this simple example where Madexcept cannot capture the error.

I'm using Delphi 12.1
MadExcept 5.1.4

I need these settings active

[madshi]

I've just compiled your project with madExcept and it catches the crash just fine for me, both in 32bit and 64bit, using Delphi 12.

[luciano_f]

Attached is a Video and an Exe for you to see the problem

https://mega.nz/file/hrB3RLAa#r8R2DKDhZ ... 9hnmiFGCdQ

[madshi]

You said madExcept cannot capture that error, but your video shows that the exception box appears just fine. So now I'm confused.

[luciano_f]

You said madExcept cannot capture that error, but your video shows that the exception box appears just fine. So now I'm confused.

For me, capturing the error is showing where the problem is in which line of code and madExcept doesn't do that

error line:

Procedure P_EndThreadLista(Sender: TObject);

[luciano_f]

See the image
and that is of no use to me,
I need to know the line of code where the error occurred

[iconic]

The tab after "unit" in the dialog is "line" but in your screen shot it's an ellipsis (...) because it is not widened/expanded. I'd recommend expanding it and investigating further than the callstack, potentially into the Disassembly area if needed for very detailed specifics about the error.

--Iconic

[luciano_f]

I didn't understand.

Can you make a video explaining it to me ?

[iconic]

Your code will stop crashing once you move your (P_EndThreadLista) function outside of your main procedure. It can't be a nested or "inline" function... meaning localized to the main function as a sub-function as this appears to be a "scope" issue. It should likely stop crashing then. That's all I can tell you after a quick check. I would study multi-threading a bit more, then it will make more sense Remove "If Sender Is TThread Then" as it's incorrect in your example and will never be a condition that is satisfied in your case as "Sender" is never assigned. Good luck to you.

--Iconic

[luciano_f]

Your code will stop crashing once you move your (P_EndThreadLista) function outside of your main procedure. It can't be a nested or "inline" function... meaning localized to the main function as a sub-function as this appears to be a "scope" issue. It should likely stop crashing then. That's all I can tell you after a quick check. I would study multi-threading a bit more, then it will make more sense Remove "If Sender Is TThread Then" as it's incorrect in your example and will never be a condition that is satisfied in your case as "Sender" is never assigned. Good luck to you.

The problem is not the error in "P_EndThreadLista", I already understood that I have to put it outside the Scope and I fixed it.
see since I posted this topic I had already fixed the error, However, I created this demo for you to fix MadExcept

the issue is that MadExcept is not being able to find the error, and this gave me a lot of work to find the issue here is another, I see a problem in MadExcept because it cannot find the line where the error is.

Don't you understand this yet ???

I created this small Demo because it a bug in MadExcept where it couldn't find the line that triggered the error.

[iconic]

As Madshi has mentioned before callstacks are not an exact science and sometimes they can be incorrect which will affect line #'s etc. madExcept can only work with the information given to it. AFAIK that's what it looks like to me but I am not the developer of madExcept so I don't have anything else to add to this. Sorry

--Iconic

[luciano_f]

As Madshi has mentioned before callstacks are not an exact science and sometimes they can be incorrect which will affect line #'s etc. madExcept can only work with the information given to it. AFAIK that's what it looks like to me but I am not the developer of madExcept so I don't have anything else to add to this. Sorry

the issue here is clear and well explained with an example where MadExcept fails to capture the error
I believe it would be good to have a corrected analysis in madExcept.

[iconic]

MadExcept fails to capture the error

If madExcept was not capturing the exception your program would throw an EAccessViolation and terminate shortly after. madExcept's exception box shows you that it is caught/captured and even allows you to successfully resume your program. Your definition of caught/captured is what is confusing and is clearly incorrect. I understand your frustration about having no real useful information here however Madshi will take a look I am sure. His invaluable information will let you know if it's a potential bug here or other (edge case where no helpful information can be harvested)

--Iconic

[luciano_f]

If madExcept was not capturing the exception your program would throw an EAccessViolation and terminate shortly after. madExcept's exception box shows you that it is caught/captured and even allows you to successfully resume your program. Your definition of caught/captured is what is confusing and is clearly incorrect. I understand your frustration about having no real useful information here however Madshi will take a look I am sure. His invaluable information will let you know if it's a potential bug here or other (edge case where no helpful information can be harvested)
--Iconic

My friend, I think you didn't read or didn't understand the question.
For me, MadExcept needs to show the line where the error is, and it isn't doing that.
Just showing an error but not showing the line of code where the problem is, Delphi does this without needing MadExcept.
The problem in my opinion is a madExcept bug and not being able to capture the error line.

[iconic]

If you read my earlier post I mentioned that you're not working with helpful information such as the line # you are seeking, just look for my post that mentioned line #. Anyhow, Madshi has informed me last night that he will take a closer look at this in the next few days to determine if this is a bug or simply what I explained earlier to you in this thread. Please be patient. TY

--Iconic