Testing error codes in debug mode

[Matthew Berg]

I am working on an application in which many of the functions employ TRY ... CATCH blocks to catch custom errors I throw with the ERROR statement. When I run my application in debug mode (Run -> Compile and Debug) I get the following error in my CATCH block where I test the current error code with the ERR or ERRCLEAR functions:

Break on error 151:
Not a valid PowerBASIC error code. Probable memory corruption.

However, in the help file it clearly states for ERR and ERRCLEAR:

Valid run-time error values are in the range 1 through 255. Attempting to set an error value (with the ERROR statement) outside of that range will convert the value to a run-time Error 5 ("Illegal function call").

If an error code of 151 is valid, why do I get the error mentioned above when running in debug mode? It doesn't prevent me from testing my application but it is incorrect and rather annoying.

The following code demonstrates this issue:

'Run this code in debug mode to see the problem.

%MyCustomErrorCode = 151

Function PBMain () As Long

  Try
    Error %MyCustomErrorCode
  Catch
    Select Case As Long ErrClear
      Case %MyCustomErrorCode
        ? "My custom error thrown."
    End Select
  End Try
  
  Function = 1

End Function

I am using PB/Win 9.01.0100.

[Stanley Durham]

this works for me
added: there was reason i used a variable to get ErrClear - don't remember why

    Try
    Catch
        Local lErr As Long : lErr = ErrClear
        Select Case As Long lErr
        Case 151 : 'handle error
        Case 152 : 'handle error
        Case 153 : 'handle error
        Case 154 :
        Case 155 :
        Case 156 :
        Case 157 :
        Case 158 :
        Case 159 :
        End Select
    End Try

[Stanley Durham]

Added note:
Everyone’s programming style is different, these debug macros may/not be helpful.

Assert like macros

They’ve been a tremendous help for me.

The macros will exit the procedure if the test fails and print a debug message, along with procedure name.

They add very little overhead, so I test everything.
Run program in debug mode and any offending procedures show right away.

The ErrGo…() macros are for use when it’s necessary to close something before exiting.

[Michael Mattias]

Break on error 151:
Not a valid PowerBASIC error code. Probable memory corruption

"Break on error 151. Not a valid PowerBASIC error code." is fact.

"Probable memory corruption" is speculation (at best).

[Cliff Nichols]

Personally I stick with my Runtime Debugging in the source code forums
(2 other versions there too but I am working on it)

Depending on how deep you take it, you will find that many languages attempt to protect you from mistakes you made (or just problems that the compiler could not handle), so why not protect you from it until it can be handled???

Most cases, a good thing, but in the few that the user REALLY wants to know then its a bad thing.

In the realm of debugging I guess the answer is the same as your application ("It Depends", or "Alice how deep do you want to see the rabbit hole go???")

[Dave Biggs]

Matthew,

I tried your code in both PBWin804 and PBWin901.
Run - Compile and Debig - Step into code but don't see the error ?

Did anyone else actually run the code?

[Gösta H. Lovgren-2]

I get the same results as Dave.

'Run this code in debug mode to see the problem.
'

'PBWIN 9.01 - WinApi 05/2008 - XP Pro SP3
#Compile Exe  
#Dim All
#Optimize SPEED 'Fly baby, fly
#Debug Display On 'off in production code
%MyCustomErrorCode = 151
Function PBMain () As Long
  Local l$
  Try
'    Error %MyCustomErrorCode
  Error 151   '<< same thing
  Catch
    Select Case As Long ErrClear
      Case %MyCustomErrorCode
  [COLOR=darkred]     l$ =  "My custom error thrown." & $CrLf & _[/COLOR]
[COLOR=darkred]       Error$(Err) & Str$(Err)[/COLOR]
[COLOR=darkred]      ClipBoard Set Text l$ [/COLOR]
[COLOR=darkred]      ? l$ [/COLOR]
    End Select
  End Try
 
  Function = 1
End Function'I am Using PB/Win 9.01

Returns:
"My custom Error thrown.
No Error 0"

Apparently 151 is not recognized as an error even if you set it. Send it on to PB Support, Matthew, and see what they have to say.

Later - ... If the Error is set BEFORE the Try I get "Untrapped Error 151" in a Msgbox. If it's set AFTER the Try, I get "No error 0". Hmmm... gets me confused thinking about it.

[Dave Biggs]

Gösta,
I reckon you get "No Error 0" because the Select Case statement is using ErrClear so by time you apply 'Error$(Err) & Str$(Err)' it is showing you that Err has in fact been set to 0. You know that it was 151 though - cause here you are in the 'Case 151' part of the proggy.
Try this instead..

    Select Case As Long Err 'Clear
      Case %MyCustomErrorCode
       l$ =  "My custom error thrown." & $CrLf & _
       Error$(Err) & Str$(Err)
      ClipBoard Set Text l$ 
      ? l$ 
      Err = 0
    End Select

When I wrote that I didn't see the error, I should have said " I don't see the

Break on error 151:
Not a valid PowerBASIC error code. Probable memory corruption.

- ie the code runs just as intended in Debug Mode with the MessageBox popping up as expected.

[Gösta H. Lovgren-2]

Gösta,
I reckon you get "No Error 0" because the Select Case statement is using ErrClear

Well I'll be a son of a dog. I NEVER saw the ErrClear in the original code, My bad.

=================================
"Luck is the residue of design."
Branch Rickey
Brooklyn Dodgers owner
=================================

[Matthew Berg]

"Break on error 151. Not a valid PowerBASIC error code." is fact.

Then the documentation is misleading.

I tried your code in both PBWin804 and PBWin901.
Run - Compile and Debig - Step into code but don't see the error ?

Well, what can I say. I run the code I posted (Run -> Compile & Debug), press F5, and the error appears in the IDE's debug/output window. This happens regardless of whether or not the SELECT ... CASE statement in the error handler uses ERR or ERRCLEAR.

I'll play around with this some more to see if I can get this error to go away.

[Dave Biggs]

Ah HA! I can see that behaviour - but only when the 'Break on Error' Debugger Option is selected!

Break on Error
Causes the debugger to stop after every statement to check the error status and then automatically halt program execution when an error occurs (non-zero ERR value). .... etc

I guess you'll need to turn this off if you are checking this kind of code

[Matthew Berg]

Ah HA! I can see that behaviour - but only when the 'Break on Error' Debugger Option is selected!

I guess you'll need to turn this off if you are checking this kind of code

Right you are... turning this off makes the error go away. I didn't even realise that option was there.

Thanks!

[Cliff Nichols]

One of your own quotes used against you......*LOL* (only meant in jest, please do not take it personally)

If you try to make something idiot-proof, someone will invent a better idiot.

I just found it funny cause you seem to be fighting the eternal engine of idiots that are created vs you being a lone programmer trying to not let then find a bug in your code (Teasing grin)