Possible to get as much debugging tips when handling exception as from unhandled crash? Topic is solved

[freespacing]

When letting a script crash without handling errors, ahk shows very useful information for debugging:


On the other hand, when I wrap the function call and try to get information out of the error object:

Code: Select all

   	Catch e {
   		msg := "An exception bubbled up to the top level.`n`n"
   		msg .=  e.message
   		msg .= "`n`nError in " e.What
   		msg .= "`nwhich was called at line " . e.Line
   		msg .= "`nof " . e.File
   		msg .= "`n`nExtra information if any:`n" . e.Extra
               etc.

The information retrieved is much more vague:

An exception bubbled up to the top level.

Can't create control.

Error in Gui
which was called at line 1525
of C:\MyScript.exe

Extra information if any:

Is there a way to get the same useful lines about where the error was found displayed during an unhandled crash via error handling, so they can be shown?

At the moment, the information is of so little help for debugging that I prefer to leave the error unhandled.

Sorry if this is a basic question!

[gregster]

Obviously, you get Can't create control. and line 1525, plus that it happenend with the Gui command.

How is this more vague than the original msgbox? I mean, assuming you are using a real code editor that shows line numbers, and not standard Notepad.
To fix it, you will have to go to that line anyway...

[freespacing]

How is this more vague than the original msgbox? I mean, assuming you are using a real code editor that shows line numbers, and not standard Notepad.
To fix it, you will have to go to that line anyway...

It's more vague because the line numbers are wrong.
The crash happens on an included file, on line 286 of that file. But the error object reports line 1525, probably because once the include directives are run the script becomes one huge file. And the file name is wrong too, it points to the script's entry point, not to the included file.

Unless there is a way to translate 1525 into specific file, line 286, the information is more vague. I have no idea where we crashed.

assuming you are using a real code editor

Off-topic: In case anyone is interested in checking it out, I am using the AHK syntax coloring scheme for EditPad Pro, which I made myself and posted on GitHub. It is the most stable AHK environment I've used for large projects — having tried AHK Studio extensively and become frustrated by a number of problems (e.g. losing code) when working with multiple files, and not being convinced by VS Code.

Apart from being beautiful and having a file navigation pane (which I didn't make) to jump between various functions, it relies on EPP, the most complete editor I know for text files (e.g. incredible regex support). Of course a JetBrains IDE would be ideal but that's not going to happen.

[gregster]

Well, you don't get line 286 out of the original messagebox either. But I agree, it will be easier to find, if you know the line text.

But I would use catch rather to serve the end user with customized error messages (or to handle known problems that can't be handled nicely by other means), not necessarily for my own basic debugging and testing.

But the addition of ListLines (or just calling it up via the script's icon) might give you a better idea, which line triggered the exception, if you really want to use catch for debugging purposes; and even giving you information about included files (as long as uncompiled). You can see it flip-flopping here between the main script and the included file (with individual line numbers):

included.png (37.48 KiB) Viewed 1777 times

(the piped file is the main script in this case)


Edit:
Related link: ScriptInfo() by Lexikos

[boiler]

not being convinced by VS Code.

Hi. Your syntax coloring system looks nice. I take it that there is no other support for AHK on EditPad Pro, such as parameter hints, debugger, etc.

Just curious whether there is anything in particular about VS Code that you don’t like (at least comparatively), or is it just that you aren’t convinced that it will not corrupt/lose your large files?

[freespacing]

But the addition of ListLines (or just calling it up via the script's icon) might give you a better idea, which line triggered the exception, if you really want to use catch for debugging purposes

Totally agree with you about debugging vs. release messages.
And ListLines was exactly what I needed.
Huge thanks!


Combining that with ScriptInfo() from Lexikos, which a search turned up, these lines can be displayed with the Error in the GUI… Bliss!

In case anyone is on the same path, a bit of clean up on the lines is required in order to avoid irrelevant lines at the front and back of ScriptInfo():

Code: Select all

Catch e {
	recent_lines := ScriptInfo("ListLines")
	recent_lines_till_crash := RegExReplace(recent_lines, "(?sm)\A.*?(^\d+:.*)^\d+: Catch,e.*", "$1")
	title := "Crashed: Exiting"
	msg := "An exception bubbled up to the top level.`n`n"
	msg .= e.message
	msg .= "`n`nError in " e.What
	msg .= "`nwhich was called at line " . e.Line
	msg .= "`nof " . e.File
	msg .= "`n`nExtra information if any:`n" . e.Extra
	msg .= "`n`n" . recent_lines_till_crash
	; Your GUI here
	ExitApp
	} 

@boiler will reply in the next message.

[freespacing]

Just curious whether there is anything in particular about VS Code that you don’t like (at least comparatively), or is it just that you aren’t convinced that it will not corrupt/lose your large files?

I had no issue with VS Code and large projects, that was just AHK Studio. Really wrestled with that, wanted to love AHK Studio but the way I wanted to work it kept messing up my code automagically.

Trying to remember what didn't work for me with VS Code. Maybe it was not possible to have a "file navigator" panel next to the file, allowing me to jump between functions in the code, listed alphabetically — important if a file has 50 functions… Maybe it was inferior search-and-replace capacities. At the time I think there were two coloring schemes for AHK, probably quite good. Can't recall precisely, sorry.

[boiler]

I see. Thanks. I also had an issue where AHK Studio lost my code (and not even stored in its automatic backups), but I was trying to use it in a way that the author warned might have issues: I was trying to view/edit the same document in multiple panes at once, which is a must-have feature for my primary editor.

[swagfag]

ideally these ahk exceptions should include a callstack, too

[Helgef]

See this tutorial by nnnik.

Cheers.

[freespacing]

OFF-TOPIC

@boiler sounds like we had similar issues.
My problems stemmed from wanting the file navigator to show just the functions for that particular file, not for the whole project. The only workaround I found was to open files independently, and that caused AHK Studio to mess up the files.

https://www.autohotkey.com/boards/viewtopic.php?f=62&t=300&start=1040#p272826
https://www.autohotkey.com/boards/viewtopic.php?f=62&t=300&start=1040#p272980 (followed by Maestrith's explanation)

My takeaway was that AHK Studio is probably the best there is for small AHK projects, but unsuitable for the kind of work I was doing at the time, where independent navigation of each file was a must. This could have been fixed since then, didn't investigate.

[swagfag]

i think lexikos needs to see this tutorial by nnnik. and also make it work for compiled scripts, and make it enabled by default. lol

[Helgef]

@swagfag, it might come,

New error dialog with stack trace, formatting changes and a few shortcut buttons.

Cheers.

[freespacing]

See this tutorial by nnnik.
Cheers.

Thank you @Helgef !
printStack() looks fantastic, filling an important gap. Will use it for uncompiled scripts, for which it is designed.
Sadly this particular project is compiled, so for that one I'll have to stick with the above.