Announcement

Collapse
No announcement yet.

Testing error codes in debug mode

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Testing error codes in debug mode

    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:
    Code:
    '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.
    Last edited by Matthew Berg; 1 Aug 2009, 08:04 AM. Reason: Add compiler version.
    If you try to make something idiot-proof, someone will invent a better idiot.

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

    Code:
        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
    Last edited by Stanley Durham; 1 Aug 2009, 12:14 PM.
    stanthemanstan~gmail
    Dead Theory Walking
    Range Trie Tree
    HLib ~ Free Data Container Lib ~ Arrays, Lists, Stacks, Queues, Deques, Trees, Hashes

    Comment


    • #3
      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.
      stanthemanstan~gmail
      Dead Theory Walking
      Range Trie Tree
      HLib ~ Free Data Container Lib ~ Arrays, Lists, Stacks, Queues, Deques, Trees, Hashes

      Comment


      • #4
        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).
        Michael Mattias
        Tal Systems (retired)
        Port Washington WI USA
        [email protected]
        http://www.talsystems.com

        Comment


        • #5
          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???")
          Engineer's Motto: If it aint broke take it apart and fix it

          "If at 1st you don't succeed... call it version 1.0"

          "Half of Programming is coding"....."The other 90% is DEBUGGING"

          "Document my code????" .... "WHYYY??? do you think they call it CODE? "

          Comment


          • #6
            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?
            Rgds, Dave

            Comment


            • #7
              I get the same results as Dave.

              'Run this code in debug mode to see the problem.
              '
              Code:
              '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.
              Last edited by Gösta H. Lovgren-2; 3 Aug 2009, 09:10 PM.
              It's a pretty day. I hope you enjoy it.

              Gösta

              JWAM: (Quit Smoking): http://www.SwedesDock.com/smoking
              LDN - A Miracle Drug: http://www.SwedesDock.com/LDN/

              Comment


              • #8
                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..
                Code:
                    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.
                Rgds, Dave

                Comment


                • #9
                  Originally posted by Dave Biggs View Post
                  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
                  =================================
                  It's a pretty day. I hope you enjoy it.

                  Gösta

                  JWAM: (Quit Smoking): http://www.SwedesDock.com/smoking
                  LDN - A Miracle Drug: http://www.SwedesDock.com/LDN/

                  Comment


                  • #10
                    Originally posted by Michael Mattias View Post
                    "Break on error 151. Not a valid PowerBASIC error code." is fact.
                    Then the documentation is misleading.

                    Originally posted by Dave Biggs View Post
                    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.
                    If you try to make something idiot-proof, someone will invent a better idiot.

                    Comment


                    • #11
                      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
                      Rgds, Dave

                      Comment


                      • #12
                        Originally posted by Dave Biggs View Post
                        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!
                        If you try to make something idiot-proof, someone will invent a better idiot.

                        Comment


                        • #13
                          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)
                          Engineer's Motto: If it aint broke take it apart and fix it

                          "If at 1st you don't succeed... call it version 1.0"

                          "Half of Programming is coding"....."The other 90% is DEBUGGING"

                          "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                          Comment

                          Working...
                          X