Variable watch when breaking on error

[Ineentho]

Hello!

I’ve recently downloaded a trail Glider and I’m loving it so far, however there is one thing that bugs me:

When debugging by setting breakpoints, I can see a list of all variables currently set. However, when the debugger forcefully breaks due to an error, I can only see three variables: _g, event and handleError. Why is that? I find it very annoying to debug errors that appear seemingly randomly.

Is that the intended way things work, some setting that I haven’t found or simply a Glider bug? It’s a major drawback for me

Thanks, Ineentho

[Ineentho]

Cleaned up the post a bit, hope somebody can answer now

[M.Y.developers]

Hello Ineentho,

Thanks for the report.

The problem is that when the error is thrown the debugger grabs variables from the current stack frame, which happens to be the error handler function itself. We are working on improving the way the call stack works so you can switch to a particular place in the call stack to pull up the variables listed there. We will let you know when we fix this issue.

Regards,

M.Y. Developers

[Ineentho]

@M.Y.developers

Hello Ineentho,

Thanks for the report.

The problem is that when the error is thrown the debugger grabs variables from the current stack frame, which happens to be the error handler function itself. We are working on improving the way the call stack works so you can switch to a particular place in the call stack to pull up the variables listed there. We will let you know when we fix this issue.

Regards,

M.Y. Developers

Thanks for the response Is there any way to go around the problem for now? Currently I have to guess what the problem is (for example a nil value), creating an if statement and setting a breakpoint inside of that if statement. I feel like there should be a better way?

[M.Y.developers]

Hello Ineentho,

You should be getting a stacktrace with the problem in the output window. Is it not showing up?

Regards,

M.Y. Developers

[Ineentho]

Cleaned up the post a bit, hope somebody can answer now

[M.Y.developers]

Hello Ineentho,

Thanks for the report.

The problem is that when the error is thrown the debugger grabs variables from the current stack frame, which happens to be the error handler function itself. We are working on improving the way the call stack works so you can switch to a particular place in the call stack to pull up the variables listed there. We will let you know when we fix this issue.

Regards,

M.Y. Developers

[Ineentho]

@M.Y.developers

Hello Ineentho,

Thanks for the report.

The problem is that when the error is thrown the debugger grabs variables from the current stack frame, which happens to be the error handler function itself. We are working on improving the way the call stack works so you can switch to a particular place in the call stack to pull up the variables listed there. We will let you know when we fix this issue.

Regards,

M.Y. Developers

Thanks for the response Is there any way to go around the problem for now? Currently I have to guess what the problem is (for example a nil value), creating an if statement and setting a breakpoint inside of that if statement. I feel like there should be a better way?

[M.Y.developers]

Hello Ineentho,

You should be getting a stacktrace with the problem in the output window. Is it not showing up?

Regards,

M.Y. Developers