Write multiple lines with ;@Debug-Output?

[Lexikos]

Currently if I write ; @Debug-Output => {e.Stack}, line breaks are replaced with the literal text `r`n and the whole thing is shown as one line. Is there a way to avoid this and just show the text as is (aside from switching to OutputDebug)?

I know there is {{callstack}}, but that doesn't contain what I want: the call stack at the time the error (e) was thrown.

I had also tried just printing {e}, but it is inconvenient: not only is it collapsed by default, but there is a single child item "e: (summary of object)" that also needs to be expanded. The child item itself isn't particularly useful, because all I can see is the class name and part of the Extra field (the rest is off the screen).

If I expand any logged object after the debugger stops, it just shows "No debugger available, can not send 'variables'". Is this a limitation of the extension system?

Is there a way to output the object expanded by default? Aside from being more convenient, I imagine that would provide a workaround for the "No debugger available" problem.

[zero-plusplus]

Currently if I write ; @Debug-Output => {e.Stack}, line breaks are replaced with the literal text `r`n and the whole thing is shown as one line. Is there a way to avoid this and just show the text as is (aside from switching to OutputDebug)?

I think there was a reason for this, but now I don't see a problem with it being printed on multiple lines.
Change to print the raw string of the variable if it is not a problem.

I know there is {{callstack}}, but that doesn't contain what I want: the call stack at the time the error (e) was thrown.

I had also tried just printing {e}, but it is inconvenient: not only is it collapsed by default, but there is a single child item "e: (summary of object)" that also needs to be expanded. The child item itself isn't particularly usef

The reason for implementing {callstack} was to break a script only when called from a specific function/method.

This idea came to me while creating a unit test library, and it would be very useful to be able to break only when called directly from a unit test.

The error object is not included because the method to retrieve it requires a slightly cumbersome implementation.

I understand that if the error object is not included when diagnosing an error, this variable has no value, so I will try to improve it.

I will try to get the error object in the following way, any other ideas?

• Treat a specific name (e, err, error, etc.) as an error object and add it to the call stack after checking
• Search variable list and add matching error object to call stack

If I expand any logged object after the debugger stops, it just shows "No debugger available, can not send 'variables'". Is this a limitation of the extension system?

This is a VSCode specification.

Is there a way to output the object expanded by default? Aside from being more convenient, I imagine that would provide a workaround for the "No debugger available" problem.

I thought the same thing and looked into it, but it seems that it is not possible to expand from the extension side due to VSCode's specifications.

---

Since the current specification is inconvenient for printing call stacks, I will add a string representation, callstacks.trace, which will be used to print out the call stacks.

Another way to print call stacks is to use this library.

In the next version, this library will be included in the extensions and can be included in debugged scripts using pseudo-variables.

---

I opened a issue related to this problem.

• Add {callstack.trace} #224
• Support for multi-line output with @Debug-Output #225
• Add information to callstack if error object exists #226

[Lexikos]

To be clear, I'm not concerned about the debugger providing error information. I just want to print text or an object with formatting that is convenient and readable to me.

I will try to get the error object in the following way, any other ideas?

The parser can look at the parameters of Catch, if there is one above the current block.

Treat a specific name (e, err, error, etc.) as an error object

For v2, it might be better to look at the object's class, which conventionally contains the word "Error". For v1, exception objects can only be identified by their properties (typically Message, What, File, Line).

[zero-plusplus]

OK.
Add the {callstack.trace} metavariable for ease of printing and include error information if possible.

The parser can look at the parameters of Catch, if there is one above the current block.

The best solution is if a parser is available. I am currently developing a treesitter parser and will eventually adopt that idea.

For v2, it might be better to look at the object's class, which conventionally contains the word "Error". For v1, exception objects can only be identified by their properties (typically Message, What, File, Line).

I am trying to get an error object from a variable list using the above method.

The problem occurs when there is more than one error object, but if I get the first error object whose what property and A_ThisFunc match exactly, the problem will be avoided in most cases.

I realized after writing the above that the what property does not necessarily match A_ThisFunc when using the what argument of the Error function.

I will hold off on the idea of including an Error object.

[derricck]

@Lexikos as you are by here, could you take a look at this issue #243?
zero-plusplus mentioned it could be a bug into the AutoHotkey debugger.