Is it possible to GetLastLine() for diagnostical reasons?

New comment
 
I guess the compiler knows at every time which of code line contains which statement. But there is no such function in functions list.

Sometimes out of range bugs are hard to find between functions and classes.

It would be convenient to have that and it should be possible I guess...?
 
It is not hard, use the debugger.
 
pennyhunter:
I guess the compiler knows at every time which of code line contains which statement. But there is no such function in functions list.

Sometimes out of range bugs are hard to find between functions and classes.

It would be convenient to have that and it should be possible I guess...?
During debug you can see the call stack.

But on release, all debug information is stripped from the compiled file.
https://www.mql5.com/en/forum/2122
 
@William Yes I know I use the debugger a lot but I would like to use it less 😁 especially setting all the stop points.

That's maybe something that I have to clarify: It would be quite convenient to be able to print the last line number upon debugger shutdown. 

@Alexandre As I get it from the other thread does it pose a bigger risk for decompilation?
 
pennyhunter #:
@William Yes I know I use the debugger a lot but I would like to use it less 😁 especially setting all the stop points.

That's maybe something that I have to clarify: It would be quite convenient to be able to print the last line number upon debugger shutdown. 

@Alexandre As I get it from the other thread does it pose a bigger risk for decompilation?
Yes, it would make it easier to reverse engineer.
 
You can get the Infos by following "macros"


As far as I have noticed, debug info is not removed from the binary when compiled.I t seems to me more like both debug and release code is inside the binary container at all times. I am not sure for market products, but if you want to test, compare the file sizes of debug version and release version. The variation is way to small.

Take a look at codebase mqlplus debug for examples on debug printing output.



 
Dominik Christian Egert #:
You can get the Infos by following "macros"


As far as I have noticed, debug info is not removed from the binary when compiled.I t seems to me more like both debug and release code is inside the binary container at all times. I am not sure for market products, but if you want to test, compare the file sizes of debug version and release version. The variation is way to small.

Take a look at codebase mqlplus debug for examples on debug printing output.



While your project to enhance debugging is great, they are not the same as the debug info the compiler
adds to the executable. I do something similar but simpler by having a "panic" macro to create a critical
error on my indicators if something goes wrong and the indicator cannot recover.

The function names and symbol tables are removed, stuff that maps memory location to names and allows
the debugger to have a call stack with the correct names. I am guessing they are also doing other optimizations.

I did a test and it made a huge difference on one of my indicators:

Release version:


Debug version:

 
Dominik Christian Egert #:
You can get the Infos by following "macros"


Nice. Carl taught me debugging the hard way and I use it a lot now but I really need to step up my error handling game. Like if(!...)print() and stuff, maybe I can use _LINE_ there. Combining Comment() and _LINE_ comes closest to what I was thinking, I have to try if the comment line stays there after debugger stops.

I was thinking an OnDebuggerStop() event would be practical for that similar to OnTesterDeinit...
Either way it raised the question why we don't have Debug related events. 

On the other hand I have no ideas what else an OnDebuggerStop event could do except show you the last line before your code crashed. But that sounded so useful.
 
pennyhunter #:
Nice. Carl taught me debugging the hard way and I use it a lot now but I really need to step up my error handling game. Like if(!...)print() and stuff, maybe I can use _LINE_ there. Combining Comment() and _LINE_ comes closest to what I was thinking, I have to try if the comment line stays there after debugger stops.

I was thinking an OnDebuggerStop() event would be practical for that similar to OnTesterDeinit...
Either way it raised the question why we don't have Debug related events. 

On the other hand I have no ideas what else an OnDebuggerStop event could do except show you the last line before your code crashed. But that sounded so useful.
During debugging, it stops at the error line and shows the call stack, you can check why the error occurred.

But yes, it would be useful to at least have a way to print the call stack on error, if exceptions never get implemented.
 
Alexandre Borela #:
During debugging, it stops at the error line and shows the call stack, you can check why the error occurred.

But yes, it would be useful to at least have a way to print the call stack on error, if exceptions never get implemented.
Is the call stack the set of classes that I use or the variables that I observed? I am not familiar with that level of machine operations yet... I am just saying if we can have GetLastError(), GetLastLine() would be a nice complimentation. 

I think if they would let you print the entire call stack, the risk of reverse engineering would be a lot greater, no?
 
pennyhunter #:
Is the call stack the set of classes that I use or the variables that I observed? I am not familiar with that level of machine operations yet... I am just saying if we can have GetLastError(), GetLastLine() would be a nice complimentation. 

I think if they would let you print the entire call stack, the risk of reverse engineering would be a lot greater, no?
They could allow us to print the mangled call stack and then we could use a source map(that would never be shipped to the client)
to get the original source code lines.

This would be similar to what most people do in javascript nowadays, the code is compressed and optimized but with a source map, you
can map instructions to the original source code.

The call stack is shown at the left window(the debug tab), its shows the functions that were called up to that point:

12
New comment
Reason: