Output all error messages to the debug console

[zero-plusplus]

AutoHotkey does not output all error messages to stderr. Also another problem is that a dialog box is generated when an error occurs.
Currently, users need to build a library into their scripts to solve these problems.

So I came up with a way to embed the library when debugging.
However, it is not possible to load the library dynamically, so the following tricks are required.

1. Copy the program to the temp folder and add the include statement for the specified library and rewrite the path to all #Include statements in the program
2. Rewrite the call stack path information to the original file and decrement the line number information only for the include statement sentences
3. skip it if it breaks in the library due to step execution, etc.
   This makes it possible to embed the library without the user being aware of it.

There are two libraries that solve the problem. This is modified and used.

1. https://gist.github.com/zero-plusplus/107d88903f8cb869d3a1600db51b7b0a
2. https://autohotkey.com/board/topic/65672-suppressing-run-time-error-messages/?hl=%252Bsuppressruntimeerrors#entry415352

The problem with this solution is that it is very labor intensive. Like the trick itself, you'll need to have a library for the each version of AutoHotkey.
Therefore, it may not be implemented immediately.

[SAbboushi]

I'm wondering if you have contacted lexikos to propose that these obstacles are resolved by future AHK releases?

[zero-plusplus]

Basically, I think this problem is something I should solve.
This is because I don't think my request is common.

What I would like to do is not to show the error dialog, instead I would like the stderr to output a message containing the call stack, and I would like the error message to show

Only the users of my extension would greatly benefit from solving this.
I don't want to take up valuable time of lexikos for that.

[zero-plusplus]

I don't think that's a very good explanation now that I see it, so I'll add.

The reasons for and benefits of implementation.

1. It works with older versions
2. I can decide the specification of the error messages. Currently, I don't have a lot of specifics, such as how to display the call stack. That's why I can't send specific requests to lexikos
3. I have the idea of embedding an external library to work with vscode in the Scriptlet I will be implementing with vscode-autohotkey. In this case, will need the feature to embed this external library to debug it

Other ideas, such as embedding libraries such as UnitTest, are also available, but they are not practical ideas yet.

In any case, it is a draft feature and is a low priority to implement.

[SAbboushi]

OK - appreciate the update

[Lexikos]

You may have noticed:

/Include was added in v1.1.34 and v2.0-a135 for things like this. If the debugger was using its own copy of AutoHotkey.exe, it could also be done by embedding the library as RCDATA resource ID 2.

The Stack property was added in v2.0-a125.

It is also possible to detect the construction of new Error objects (even by built-in code) in v2.0-a125+ by hooking Error.Prototype.__New (replacing it with a new function which calls the old function), although the hook may cause an additional entry in Stack, and errors can be constructed without being thrown. (If Object.Call is at the top of the call stack, it's being constructed by the script; otherwise it's probably an error about to be thrown by built-in code.)

What I would like to do is not to show the error dialog, instead I would like the stderr to output a message containing the call stack, and I would like the error message to show

The debugger client could probably do that without injecting or modifying script, if it had the use of exception breakpoints, which are supported within the DBGP spec but not my current implementation.

I have intended to add support for it for a long time, but it's never been a particularly appealing project, given that making use of it would mean also adding support in a debugger client. I think implementing support within the engine would probably be relatively trivial.

The DBGP spec was updated on 2021-05-04 to add breakpoint_details, which allows the engine to tell the client which breakpoint was hit (in response to a continuation command). In retrospect, that seems essential to actually making use of exception breakpoints.

I don't see any way within the DBGP spec to communicate the actual exception value or message, only the exception name (type?). I would probably implement a pseudo-property which could be retrieved by property_get. PhpStorm's documentation gave me the impression that they do it by eval'ing PHP's error_get_last().

[zero-plusplus]

/Include was added in v1.1.34 and v2.0-a135 for things like this. If the debugger was using its own copy of AutoHotkey.exe, it could also be done by embedding the library as RCDATA resource ID 2.

I just checked. This is convenient.

It is also possible to detect the construction of new Error objects (even by built-in code) in v2.0-a125+ by hooking Error.Prototype.__New (replacing it with a new function which calls the old function), although the hook may cause an additional entry in Stack, and errors can be constructed without being thrown. (If Object.Call is at the top of the call stack, it's being constructed by the script; otherwise it's probably an error about to be thrown by built-in code.)

It's interesting how to pseudo detect the occurrence of a exception by hooking the creation of an error object. The side effects might be a concern for actual use.

The debugger client could probably do that without injecting or modifying script, if it had the use of exception breakpoints, which are supported within the DBGP spec but not my current implementation.

I have intended to add support for it for a long time, but it's never been a particularly appealing project, given that making use of it would mean also adding support in a debugger client. I think implementing support within the engine would probably be relatively trivial.

Exception breakpoints are a very desired feature for debug adapter creators.

The DBGP spec was updated on 2021-05-04 to add breakpoint_details, which allows the engine to tell the client which breakpoint was hit (in response to a continuation command). In retrospect, that seems essential to actually making use of exception breakpoints.

I don't see any way within the DBGP spec to communicate the actual exception value or message, only the exception name (type?). I would probably implement a pseudo-property which could be retrieved by property_get. PhpStorm's documentation gave me the impression that they do it by eval'ing PHP's error_get_last().

I also checked the spec, and indeed there is no way to notify the error message. I agree with you about using pseudo-properties as a solution.

I have the impression that DBGP is a PHP-only protocol, although it is called "common debugger protocol", so I guess they didn't include it in the specification because error message retrieval can be solved on the language side.

[zero-plusplus]

This issue can be easily solved by using the /include argument to include an external script that catches all errors.

However, this argument can only specify one script, so if the debugger adapter uses it, the user will not be free to include external scripts.

Therefore, the solution is to create a temporary script that combines specified scripts, and specify it in /include.

[Lexikos]

However, this argument can only specify one script

Supporting multiple didn't seem to be worth the extra development time and increase in code size. It is intended mainly for use by programs or scripts and not direct use by a user at a command prompt, so convenience isn't much of a factor.

If multiple files are required, /include can specify a file that #includes other files.

If stdin isn't being used for something else, /include * can be used to avoid the need for a temporary file.

[zero-plusplus]

Thanks. The information in /include * is very useful to me.

I will add a new launch.json attribute that wraps /include.

[zero-plusplus]

When using /include *, Node.js seems to require the use of execSync and spawnSync.

However, they cannot be used for debugging purposes because they make the script wait until it finishes.

Therefore, when specifying two or more files, I will implement the method of creating a temp file as initially planned.