Announcement

Collapse
No announcement yet.

Possible enhancement to the ERROR statement?

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

  • Possible enhancement to the ERROR statement?

    Since I'm not sure where to post a request for a language enhancement, I guess I'll post it here:

    I was working with some functions today and I wanted to have them bubble-up any system errors to their caller. So I tried the following:

    Code:
     
      Try
        ' The function either completes successfully (0) or returns 
        ' the system error (non-zero) it encountered.
        '
        Error SomeFunction(n)
     
      Catch
        ' Bubble-up the system error to the caller.
        '
        Function = Err
        Exit Function
     
      End Try
    What I ended up doing was a bit more wordy. I had to store the result of the function and then test for a non-zero condition before setting an error condition:

    Code:
     
      Try
     
        ' The function either completes successfully (0) or returns 
        ' the system error (non-zero) it encountered.
        '
        intErrValue = SomeFunction(n)
        If intErrValue <> 0 Then Error intErrValue
     
      Catch
        ' Bubble-up the system error to the caller.
        '
        Function = Err
        Exit Function
     
      End Try
    So, what I was wondering is this:

    Could PB's ERROR statement be changed to allow an "ERROR 0" to not generate any error condition at all instead of mapping ERROR 0 to ERR=5 (illegal function)?

    Error trapping is our friend and I can see other circumstances where I might want to set an error condition via the result of a calculation without having to always check for a non-zero condition first before invoking the ERROR statement.

    Does anyone else feel this way? Or am I missing a solid reason why the ERROR statement should work the way it currently does?

    -Wes
    Last edited by WesWesthaver; 2 Mar 2009, 02:47 PM.

  • #2
    I'm not so sure it's wise to use the ERROR statement in a TRY.. CATCH block. That might actually be the cause of your ERROR 5 which is getting caught.

    TRY.. CATCH was not really made to detect error codes from other procedures, it was designed to catch runtime errors which occur during the execution of an intrinsic function

    You code may as well be
    Code:
        ' The function either completes successfully (0) or returns 
        ' the system error (non-zero) it encountered.
        intErrValue = SomeFunction(n)
        If intErrValue <> 0 Then 
           ' Bubble-up the system error to the caller.
            Function = Err
           Exit Function
       ELSE
         ... nothing bad happened, so continue
       END IF
    i.e, TRY..CATCH in this case is at best overkill and at worst the cause of your ERROR 5.

    BTW, all New Feature Suggestions should be sent via email to [email protected]

    MCM
    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      <COMPILE-able code not shown>
      (Sorry but had to say it)

      Could PB's ERROR statement be changed to allow an "ERROR 0" to not generate any error condition at all instead of mapping ERROR 0 to ERR=5 (illegal function)?
      well if I read the docs correctly
      ERRCLEAR, when used as a statement, is equivalent to ERR = 0.
      and Error code 0 =
      Error 0 - No errorError 0 - No error
      so without code I am unsure why you think 0 is mapping to 5???
      Error 5 - Illegal function callError 5 - Illegal function call
      If you can post some code demonstrating, then we can find what I suspect is a programming error more than a "Error-Mapping" problem
      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


      • #4
        I figured I was going to have to defend this one

        The PB online help docs say:

        Valid errors are in the range 1 through 255.

        Attempting to set an error value outside of that range will convert the value to a run-time Error 5 ("Illegal function call").

        The compiler reserves codes 0 through 150, and 241 through 255 for run-time errors. You may freely use error codes 151 through 240 for your own purposes.
        As you can see the docs clearly state that setting ERROR 0 will generate a run-time error 5 because 0 is outside the legal range of 1 through 255.

        Here's some compilable code to demonstrate:

        Code:
         
        #Compile Exe
        #Dim All
        Function PBMain () As Long
          Try
            Error 0
         
          Catch
            ? Str$(Err)
         
          End Try
         
        End Function
        As for the recommendation to NOT use ERROR within a Try/End Try block, again, the docs actually recommend it:

        ERROR ErrNum causes a run-time error to be generated and sets ERR to ErrNum. Run-time errors are only caught if you have an active ON ERROR GOTO in your code. ERROR is useful to explicitly raise an exception in a TRY/END TRY block.
        Besides, the Try/End Try construct has so much to recommend it. It is so much cleaner and more structured than the former ways of trapping errors. They don't invent these things just for the fun of it... I particularly like the mostly un-noticed and under appreciated "Finally" clause. It's the best part of the try/catch/finally construct.

        And elsewhere in the docs you'll find that error 0 is actually defined as:

        Error 0 - No error
        No error (%ERR_NOERROR)
        So I would argue that it should be ok to have an ERROR 0 statement that doesn't actually generate a runtime error.
        Last edited by WesWesthaver; 2 Mar 2009, 10:18 PM.

        Comment


        • #5
          There are two intrinsic notions to the concept of an error (exception) and an error number:

          1- The error number is set to a numeric value, which may later be retrieved. 2- An error condition is generated, which triggers a branch to the ON ERROR GOTO target, or the CATCH clause.

          When PowerBASIC creates an error, both occur. When you execute ERROR n&, a true PowerBASIC error is emulated, so both occur. When you execute ERR = n&, only #1 occurs, because you are simply saving a new ERR value for later retrieval -- that is, no error condition is generated.

          The ERROR statement accepts a numeric argument in the range of 1 to 255. If you execute ERROR with an argument of zero, an error 5 is generated to warn you that you used an illegal value. PowerBASIC recommends that using ERR = 0 is typically a better choice.

          Bob Zale
          PowerBASIC Inc,

          Comment


          • #6
            I didn't know you could assign a value to ERR.

            So I RTFM.

            Look what I found:
            To explicitly raise an exception in a TRY/END TRY block, use the ERROR statement
            So I guess using ERROR in TRY/CATCH is not a problem after all.

            Learn something every day.
            Michael Mattias
            Tal Systems (retired)
            Port Washington WI USA
            [email protected]
            http://www.talsystems.com

            Comment


            • #7
              Originally posted by Bob Zale View Post
              There are two intrinsic notions to the concept of an error (exception) and an error number:

              1- The error number is set to a numeric value, which may later be retrieved.

              2- An error condition is generated, which triggers a branch to the ON ERROR GOTO target, or the CATCH clause.

              When PowerBASIC creates an error, both occur. When you execute ERROR n&, a true PowerBASIC error is emulated, so both occur. When you execute ERR = n&, only #1 occurs, because you are simply saving a new ERR value for later retrieval -- that is, no error condition is generated.

              The ERROR statement accepts a numeric argument in the range of 1 to 255. If you execute ERROR with an argument of zero, an error 5 is generated to warn you that you used an illegal value. PowerBASIC recommends that using ERR = 0 is typically a better choice.

              Bob Zale
              PowerBASIC Inc,
              I don't contest any of what you've said. But I think that executing an ERROR 0 should be allowed without generating an exception.

              Executing any non-zero ERROR generates the intended exception. ERROR 0 is the only oddball in that it ultimately generates an error 5.

              Besides, setting Err=0 doesn't really address the point of my original post. I was hoping to be able to control the flow of a program through the use of the ERROR statement. As it stands, I can never have a scenario where my code has:

              Code:
              ...
              ...
              ERROR x ' where x is a calculated value because x will always cause an exception
              ...
              ...
              Instead I have to bracket the ERROR statement with something like:

              Code:
              If x <> 0 Then
                ERROR x
              End If
              This is just my opinion of course.
              Last edited by WesWesthaver; 3 Mar 2009, 03:49 PM.

              Comment


              • #8
                Originally posted by WesWesthaver View Post
                I don't contest any of what you've said. But I think that executing an ERROR 0 should be allowed without generating an exception
                There's no contest. I was just explaining the way it has worked for the past 18 years. Quite a few programs on this planet rely on that behavior.

                Executing any non-zero ERROR generates the intended exception. ERROR 0 is the only oddball in that it ultimately generates an error 5.
                Not exactly. There are no "oddballs" in PowerBASIC. There are actually 4,294,967,041 numeric values which are illegal with the ERROR statement. Each of those numeric values generate a valid exception because they are outside the legal range of 1 through 255.

                Besides, setting Err=0 doesn't really address the point of my original post.
                Unfortunately, it's not usually possible to automatically satisfy the desires of every single customer. If enough PowerBASIC users contact [email protected] with this request, it's a sure thing we'll listen carefully. At this point, however, [email protected] hasn't yet received even one request.

                Best regards,

                Bob Zale
                PowerBASIC Inc.

                Comment


                • #9
                  I was hoping to be able to control the flow of a program through the use of the ERROR statement.
                  Just one man's opinion, but I think you should look for plan B. ERROR is not a "flow control" tool. Strangely enough, it was designed to help with "error" handling.

                  Maybe you were looking for something like "ON X GOTO|GOSUB SomeLabel?"

                  Or maybe even "CALL|GOSUB DWORD address?"

                  MCM
                  Michael Mattias
                  Tal Systems (retired)
                  Port Washington WI USA
                  [email protected]
                  http://www.talsystems.com

                  Comment


                  • #10
                    Originally posted by Michael Mattias View Post
                    Just one man's opinion, but I think you should look for plan B. ERROR is not a "flow control" tool. Strangely enough, it was designed to help with "error" handling.
                    What does ERROR do? It vectors you off into an error handler. Any statement that has the ability to direct the path of program execution is by definition a means of "flow control."

                    I don't draw any distinction between flow control inside an error handler or outside an error handler. In some ways it hinders you as a programer to see them as two seperate environments.

                    Anyway, I was just making a suggestion for a possible expansion of an existing construct. Just a suggestion. I can live with bracketing the error statement inside a conditional test to get the desired result. I simply feel that it would be more elegant to allow for an ERROR 0 to be a "do nothing." exception. I think it would fall under the "Law of least astonishment" to see it operate this way.

                    I guess I should let this one go now... I don't want to keep beating a dead horse. Although I enjoyed getting everyones feedback on the idea.

                    -Wes
                    Last edited by WesWesthaver; 3 Mar 2009, 09:08 PM.

                    Comment


                    • #11
                      I simply feel that it would be more elegant to allow for an ERROR 0 to be a "do nothing." exception. I
                      So send in a New Feature Suggestion to [email protected].

                      I've sent in a lot which never saw the light of day. Then again, I've submitted quite a few which have.
                      Michael Mattias
                      Tal Systems (retired)
                      Port Washington WI USA
                      [email protected]
                      http://www.talsystems.com

                      Comment

                      Working...
                      X