[v2] and debugger / file path information

[SAbboushi]

I've asked the developer of the vscode debugger extension to provide hyperlinks in debugger output pane to jump to the relevant script line.
He has done so - but it doesn't work for all errors. His explanation is:

In case of an error that occurs during execution, for some reason AutoHotkey does not output the file path information.

An example of this is

Code: Select all

TraySetIcon("a") ; Error:  Can't load icon.

Relevant thread

[lexikos]

If the DBGp client has redirected stderr (as I assume is the case here), AutoHotkey outputs the exact text that would be shown in an error dialog, or is shown in the error dialog. It is designed to be displayed in the error dialog, not for consumption by the debugger. If the error occurs in an #include file, the text begins with Error in #include file "path-of-file":. It is assumed that the full path of the main script file would be unnecessary noise, so in that case the text begins with Error:. If you receive an error message in the latter form, you can assume it comes from the main script file.

In either case, no line number is given. I believe this feature was added by fincs via the merge with AutoHotkeyU (Unicode support); I did not originally intend to add it, and do not make use of it. Perhaps I would if the format was changed to be the same as #ErrorStdOut, which several editors (including Visual Studio and SciTE) understand and can jump to.

I've long planned to make use of DBGp's "exception breakpoints" to allow breaking into the debugger when a runtime error occurs, but haven't got around to it. In that case, the debugger can get the entire call stack instead of just the file/line at the top. Technically, it's already possible if the client sends commands while the error dialog is showing. (The client can make use of async support, or can be attached to the script after the error dialog appears by posting AHK_ATTACH_DEBUGGER.)

[SAbboushi]

Thanks - I'll forward to the developer.

[zero-plusplus]

As I don't speak English, I use machine translation.

Nice to meet you, I'm the developer of the extension that SAbboushi introduced to me.
Thank you for the detailed explanation.

Thanks to you, I have come up with a solution to the problem, but I have found one problem.
In the case of an error caused by `throw`, the debugger does not output a message to stderr.
But in the case of the SAbboushi example, it does.

Is there any reason for this?

[lexikos]

It's mostly because I never wanted or used that feature, as I mentioned. I probably had forgotten it at the time I wrote the code for displaying unhandled exceptions. Checking the relevant commit shows that originally it would have printed the message "Unhandled exception!" to stderr, because LineError (the main function used for runtime errors) was called.

Note the current documentation:

Sends any syntax error that prevents a script from launching to stderr rather than displaying a dialog.

Send syntax errors that prevent a script from launching to stderr rather than displaying a dialog. See #ErrorStdOut for details.

Sending runtime errors to stderr contradicts that. However, runtime errors aren't sent to the actual stderr - they just generate DBGp stderr packets if the debugger client has requested them. We don't actually support redirecting stderr to the debugger, so the only stderr packets the debugger gets are from runtime errors or OutputDebug.

I think you already noticed that OnError can be used to report unhandled exceptions a different way.

[zero-plusplus]

I missed the #ErrorStdOut specification. Thanks for letting me know.

I understand that using OnError is a superior method, but that method requires the user to prepare the code, and I'd like to deal with it on the debug adapter side if possible.

For this, requires the feature to change the output of all runtime errors to stderr instead of a dialog.
Is it possible to implement this feature?


Apart from this, I'm going to see if I can solve this problem in my current environment based on the tips you gave me.