Possible enhancement to the ERROR statement?

[WesWesthaver]

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:

 
  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:

 
  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

[Michael Mattias]

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

    ' 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

[Cliff Nichols]

<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

[WesWesthaver]

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:

 
#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. :worship: 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.

[Bob Zale]

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,

[Michael Mattias]

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.

[WesWesthaver]

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:

...
...
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:

If x <> 0 Then
  ERROR x
End If

This is just my opinion of course.

[Bob Zale]

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.

[Michael Mattias]

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

[WesWesthaver]

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

[Michael Mattias]

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.