Error handling conventions

[Mechaflash]

Error handling probably takes up the largest chunk of time for me as many of my applications need to be able to report, clearly, what's going on and what went wrong so that a newbie could understand how to troubleshoot the application if something were to go wrong.

A paradigm I've been using is a function with an If...elseif... nested with Switch...Case... utilizing up to 3 arguments.

Func _Error($err, $ext, $other = "")
  ;Errors for INI access errors. $other returns the parent function that caused the error.
  $sMsg = $err & "-" & $ext & " - "
  If $err = 1 Then
    Switch $ext
      Case 1
        $sMsg&='Error reading INI file at "' & $other & '"'&@LF&@LF& _ 
                       'This application will now close.'

      Case 2      
        $sMsg&='Error writing to INI file at "' & $other & '"'&@LF&@LF& _ 
                       'This application will now close.'

    EndSwitch
    ;Each IF statement will have it's own msgbox and Exit functions based on the type of error
    msgbox(16 + 262144, @ScriptName & " - Error!", $sMsg)
    Exit 1
  ;Errors in some other category... etc.
  ElseIf $err = 2 Then
    Switch $ext
      Case
        [...]
    EndSwitch
    ;Each IF statement will have it's own msgbox and Exit functions based on the type of error
    msgbox(16 + 262144, @ScriptName & " - Error In Something Else.", $sMsg)
    _Exit(2)
  EndIf
EndFunc

Does anyone else have their own method of performing error handling?

[water]

I like the IBM (mainframe) way of categorizing the "error" message.

This makes reading an error log much easier because every line has the same format at the beginning.

Each message has a uniqe ID so you know which application and which module issued the message and one of the following categories:

I - Information: Nothing went wrong, it's just to inform you how the function did processing

W - Warning: The processing ended properly but there is something you may need to check

E - Error: The processing ended prematurely (controlled)

S - Severe: The processing crashed and a dump was taken

A warning message looks like this:

04/24/2012 17:31:10 DMSANS1496W Duplicate include/exclude option.

[Mechaflash]

Cool. Thanks for that bit of info water.

[czardas]

I have started to develop my own system for handling errors in certain types of nested functions. I imagine it's nothing new but I'll describe the process (you might find it interesting):

I set a global variable to zero before executing a line of code. The first line of every function within the expression checks that the global flag equals zero before continuing. An error is thrown if the global flag is greater than zero. When any error occurs, the flag is incremented (a cascading error count). This makes it possible to track back to the function where the initial error occured. Since I made and about it, the system has improved a lot. It's early days though and a number of changes are likely.

Edited August 15, 2012 by czardas

[Mechaflash]

@czardas

Correct me if I'm wrong... your method requires your global variable to be incremented at the start of each function. So what you end up with is a variable that holds a count for how many functions are ran?

[czardas]

No. The global flag is set to zero before an expression which contains multiple nested functions. The flag only starts to be incremented when the first error is encountered. Here is an example: the functions are currently part of an unfinished UDF so you can't run the code (yet) I'm afraid, but hopefully you will see what I mean.

$_KickBack_ = 0 ; Global cascading error flag set to zero
$ret = _BitNOT (_Hex (_BaseToBase (1010, 2, 10), 5)) ; Expression

If $_KickBack_ > 0 Then MsgBox(0, "Error", $_KickBack_)

If no errors occur then the flag will still be zero.

If an error occurs within the function _BitNOT then the flag will be 1

If an error occurs within the function _Hex then the flag will be 2

If an error occurs within the function _BaseToBase then the flag will be 3

The expression itself is just a test expression and has no real meaning (it evaluates to -11).

Note that some AutoIt functions (such as BitNOT) do not have error codes so to accomplish this I need to add them. I must point out that this idea is not standard practice, as far as I know. It's not important enough to spend lots of time on. I posted it out of passing interest for anyone.

Edited August 15, 2012 by czardas

[Mechaflash]

ahh i see. It allows you to track which nested function throws the error in a stack... interesting.

[czardas]

ahh i see. It allows you to track which nested function throws the error in a stack... interesting.

Yes and it also avoids running any subsequent functions once an error has occured. It just counts them instead.

It's work in progress, and currently seems quite stable after I tried many bad or wrong approaches. It's interesting to hear how other people handle errors. There are definately many possible approaches to this.

Edited August 15, 2012 by czardas