Godot editor debugger doesn't give full stacktrace info for Mono exceptions

[realManix]

Bugsquad edit: See #14822 for a clear description of the issue and how to fix it.

---

Operating system or device, Godot version, GPU Model and driver (if graphics related):
Windows 10
Godot 3.0 beta 1

Issue description:

When a exception occurs in a C# script, the debugger doesn't display very helpful information, such as the name of the script that caused the error, and the line where it happened.

Steps to reproduce:
Add a C# script to any node and try to produce a NullReferenceException in any Godot callbacks.
E.g.,
in _Ready(),
string nullStr = null;
int i = nullStr.Length;

When you run the code, the debugger will tell you that a NullReferenceException has been raised, but it won't tell you where it happened.

Link to minimal example project:

[mhilbrunner]

cc @neikeq :)

[neikeq]

You mean the Godot editor debugger, right? We need to implement ScriptLanguage::debug_get_current_stack_info() and use StackTrace to get the StackFrames.

[PJB3005]

Ok so. This actually does work perfectly fine.

... On MacOS.

[neikeq]

@PJB3005 I guess you mean #14822 :) This is a different one.

[PJB3005]

oh I only see it now, this one is about the menu cutting off anything except the exception header. Right.

Might wanna remove the thing about --debug because stack traces work either way in .NET. The file and line numbers are the difference.

[akien-mga]

We have now entered release freeze for Godot 3.0 and want to focus only on release critical issues for that milestone. Therefore, we're moving this issue to the 3.1 milestone, though a fix may be made available for a 3.0.x maintenance release after it has been tested in the master branch during 3.1 development. If you consider that this issue is critical enough to warrant blocking the 3.0 release until fixed, please comment so that we can assess it more in-depth.

[realManix]

I think this should be a 3.0 milestone since without proper debugging support, developing in C# could be really tough because it would be hard to tell where the exceptions are coming from unless they are user-defined exceptions.

[akien-mga]

I think the recommended workflow for now is to use a full-fledged C# IDE for debugging, and not Godot's debugger. Ideally it should be possible to get decent debugging support in Godot itself, but if it comes only in 3.1 / 3.0.1, it should not be a showstopper IMO.

But I'll let @neikeq and @Hinsbart comment further as they are more familiar with the C# workflow.

[mysticfall]

I also think it'd be worthwhile to include this along with #15234 to be moved to 3.0 milestone. The reason is because many people will try Godot 3.0 once it gets released, as it's the first major release with C# support.

However, if they see it's almost impossible to read error messages or to find out where they occurred, it'd probably give them a bad impression and prevent them from doing a serious project with it.

I suppose even seasoned developers of C# would find it very difficult to debug the project without being able to read the stacktrace. Having a remote debuger in an IDE helps, but it's mostly used to find out why a certain error has occurred, rather than to see what error has occurred and where.

Currently, I'm using Rider which is a very capable IDE for C# and it works well with Godot's remote debugging feature, but I have to rely on my 'gut feeling' and adding a lot of GD.Print messages to track down a problem in Godot. I suppose it's not the type of experience that we'd want to present to those who come to try Godot for the first time.

So I wish we could include both of the issues in 3.0 milestone if it wouldn't take too much time to fix, to ensure Godot to be at least a viable option to develop real game projects in C# for new users.

[PJB3005]

Yeah, I agree. Also, there literally is an unused panel inside the error window to show stack traces, and it's not used. Using a proper IDE is a good idea but it doesn't mean we can't make the Godot editor not worthless too.

…

On 7 Jan 2018 05:39, "Xavier Cho" ***@***.***> wrote: I also think it'd be worthwhile to include this along with #15234 <#15234> to be moved to 3.0 milestone. The reason is because many people will try Godot 3.0 once it gets released, because it's the first major release with C# support. However, if they see it's almost impossible to read error messages or to find out where they occurred, it'd probably give them a bad impression and prevent them from doing a serious project with it. I suppose even seasoned developers of C# would find it very difficult to debug the project without being able to read the stacktrace. Having a remote debuger in an IDE helps, but it's mostly used to find out why a certain error has occurred, rather than to see what error has occurred and where. So I wish we could include both of the issues in 3.0 milestone if it wouldn't take too much time to fix, to ensure Godot to be at least a viable option to develop real game projects in C# for new users. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14589 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHu1w2OIYzVTDNcL7HJxx6kbQEj4nu8zks5tIEp3gaJpZM4Q-2Jd> .

[realManix]

The file name still doesn't seem to appear properly though? For some reason it says: "C Source: 0". Tested on RC 2 Mono.

[mysticfall]

@realManix Could it be a similar issue as #15885?

[neikeq]

@realManix are you on Windows? it sounds like #14822

[realManix]

@mysticfall I don't think so, for one I'm using C# and the all the details of the errors (or Exceptions, in my case) seem to be displayed, just not as it should. In my case, the debugger doesn't show me the file name of the script that raised the Exception, but I also just realised that it does display the full signature of the method from which the Exception was raised--which includes the class name--so I guess I can still find out the source of the error.

[realManix]

@neikeq I think this is more closely related to the original problem I had, which seems to be somewhat resolved in #15463, but this new feature seems somewhat buggy.

The helper text says "C Source: :0" where it should tell me the file name--I think?--but I figure you can still deduce from "MySpatial._Ready() in the stack trace anyways, so this does not seem like a severe issue.

[neikeq]

It really sounds a lot like #14822 (stack traces not including file location on Windows).

[realManix]

I guess so then. I thought it was different because I recall seeing that issue posted before stack trace was implemented in #15463, but the title does sound about right.