Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

suppressing run time error messages?


  • Please log in to reply
8 replies to this topic
wakewatcher
  • Members
  • 254 posts
  • Last active: Oct 04 2011 10:03 PM
  • Joined: 15 Jul 2006
Is there a way to suppress run time error messages? Once I distribute a script or two I'd prefer to be able to turn off the run time failure message where it displays many lines before and many lines after. Just a message such as "crashed at line x" would be great. I was hoping something like #ErrorStdOut would work to send stuff out to null but haven't figure anything out yet.

MacroMan!
  • Members
  • 604 posts
  • Last active: Mar 20 2012 11:40 AM
  • Joined: 28 Aug 2009
Before you send your code out to clients, you shouldn't have any errors.

AHK is pretty reliable with showing errors. If you design it right, if you don't get any when you first run it, you will prob never get errors.
What ever happened, happened.

wakewatcher
  • Members
  • 254 posts
  • Last active: Oct 04 2011 10:03 PM
  • Joined: 15 Jul 2006
MM!,

In your excitement to pontificate you missed the point...

(My thread so my turn....)

Absolutely all software development in the truest sense is a business proposition (commercial or not.) This has nothing to do about being "pretty reliable" blah blah blah. It's about being fit for purpose. For some purposes ultra reliability is key. (I know this first hand having worked doing system integrity software for Bell Labs ensuring that their cellular infrastructure software got itself back on track when coding failures were trapped.)

My AHK projects are big and complex but not life and death critical such that they need to be ultra reliable. (For instance in telecommunications you got to make sure that 911/999 always works and certainly that the 'red' phone always works no matter what.) Again understanding that all software development is a business process then my time is much better spent adding new features and functions rather than spending hundreds of hours testing every possible condition. And of course where does it stop? Do I also have to test the libraries (sqlite for example) that I beg, borrow or steal?

No it's all about being fit for purpose.

I've built in pretty good system integrity insuring that all my data commits are very regular, I upload massive amounts of data to Amazon's S3 service and automatically back up my databases to two physically differentiated servers. However because I download code segments at run time and set dynamic variables I've seen on rare occasions (once) that a created dynamic variable name was invalid causing a crash. (That was an easy enough fix but someday everyone discovers the axiom with some humility that... There is always one more bug...)

I could spent days and days testing but I'd rather spend that time working on the next heuristic for my application. And because of the general robustness otherwise it's perfectly acceptable for it to crash once in a blue moon. I'd just rather that it didn't spew out 20 lines of code when it does.
.

SKAN
  • Administrators
  • 9115 posts
  • Last active:
  • Joined: 26 Dec 2005
You could run a second script to monitor the first one.

wakewatcher
  • Members
  • 254 posts
  • Last active: Oct 04 2011 10:03 PM
  • Joined: 15 Jul 2006
Hi Skan (from whom I've borrowed a lot from! :) )

I actually use a second script as my file buffer/server to the S3 accounts and the two processes also perform as heart beat monitors to restart the other if they need to. But all I'm trying to do here (and in reality it's not the end of the world if its not possible) is to eliminate the verbosity of a run time error. Actually I don't want to make a mountain out of a mole hill. Compiling actually cuts way down on the error message clutter. But still a quiet mode would be nice.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
Currently there isn't any built-in way to do it. However, the following should suppress most (if not all) built-in run-time error messages for the current script:
SuppressRuntimeErrors("Error at line {#}.  Please contact support.")
MsgBox % %empty%  ; Normally "This dynamic variable is blank."
return

SuppressRuntimeErrors(NewErrorFormat)
{
    ; Call self-contained helper/message-monitor function:
    return SuppressRuntimeErrors_(NewErrorFormat, 0, 0, 0)
}

SuppressRuntimeErrors_(wParam, lParam, msg, hwnd)
{
    ; Constants:
    static WM_COMMNOTIFY := 0x0044, AHK_DIALOG := 1027
    ; Persistent variables:
    static sScriptWnd := 0, sScriptPID, sOnCommNotify, sMessage
    
    Critical 1000
    
    dhw := A_DetectHiddenWindows
    DetectHiddenWindows On
    
    if hwnd     ; Called internally to handle a WM_COMMNOTIFY message.
    {
        if (hwnd = sScriptWnd  ; Script's main window is the recipient.
            && wParam = AHK_DIALOG  ; We're showing a dialog of some sort.
            && WinExist("ahk_class #32770 ahk_pid " sScriptPID))
        {
            ControlGetText msg, Static1
            ; The following relies on the fact that all built-in error
            ; dialogs use this format to point out the current line:
            if RegExMatch(msg, "m`a)^--->`t0*\K\d+(?=:)", line)
            {
                ; If we change the text, the dialog will still be sized
                ; based on the previous text.  So instead, close this
                ; dialog and show a new one.
                WinClose
                StringReplace msg, sMessage, {#}, %line%
                MsgBox 48,, %msg%
            }
        }
        
        ; Restore the setting to its thread-default.
        DetectHiddenWindows %dhw%
        
        ; The following calls the script's WM_COMMNOTIFY handler if it
        ; has one, otherwise it silently fails and returns nothing:
        return %sOnCommNotify%(wParam, lParam, msg, hwnd)
    }
    else        ; Called by script.
    {
        sMessage := wParam
        
        ; If we're already registered, just return.
        if OnMessage(WM_COMMNOTIFY) = A_ThisFunc
            return
        
        ; Retrieve previous message handler, if the script has one.
        sOnCommNotify := OnMessage(WM_COMMNOTIFY)
        
        ; Retrieve hwnd of main window (usually hidden) and process ID.
        Process Exist
        sScriptPID := ErrorLevel
        sScriptWnd := WinExist("ahk_class AutoHotkey ahk_pid " sScriptPID)
        
        ; Register message handler.  Since hotkeys and other things can
        ; launch new threads while we're displaying our error dialog,
        ; pass 10 for MaxThreads so that we can catch any error dialogs
        ; that these other threads might display:
        OnMessage(WM_COMMNOTIFY, A_ThisFunc, 10)
        
        ; Since we were called by script, restore our caller's setting.
        DetectHiddenWindows %dhw%
    }
}


wakewatcher
  • Members
  • 254 posts
  • Last active: Oct 04 2011 10:03 PM
  • Joined: 15 Jul 2006
That's what I'm talking about. Absolutely perfect for my needs! Thanks.

Siavash
  • Members
  • 1 posts
  • Last active: Feb 21 2013 08:00 AM
  • Joined: 21 Feb 2013

Old topic and the OP's problem is fixed, but for others that simply don't want to see any errors:

 

Use "try" before calling a function then "catch e" with nothing afterward to show nothing.

 

Link to doc: http://l.autohotkey....ommands/Try.htm



Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

Catch is optional, so for example, try MsgBox % %empty% fails without displaying any errors.