OpenEuphoria

Re: [Windows] Associate file extensions with a program

• Posted by "Juergen Luethje" <j.lue at gmx.de> Oct 12, 2004
• 446 views

Derek Parnell wrote:

> Juergen Luethje wrote:

<snip>

>> Unfortunately, it's not possible anyhow, to consistently return errors
>> as function values. E.g. in many math functions, we can't return a
>> number such as -1, 0 or 1 as error values, because these values might be
>> normal results of that function.
>> We could return e.g. {} to inicate an error, or even {1}, {2} to
>> indicate specific errors. But there are also functions, that legally can
>> return arbitrary objects.
>
> I've been using the method of always returning a sequence; the first
> element is the return code and the second is the function value.

Ah, yes.. I couldn't see the wood for the trees. 

>> I'll think about my habits in this regard. Maybe it's cleaner to use a
>> global error variable.
>
> A simple global error variable is a *bad* idea. It can lead to subtle
> bugs if you cannot guarentee that the function you called is the *only*
> function that sets the single shared error variable.

I'd be interested in your opinion about the following two
implementations.

-- Implementation #1
integer ErrNo
ErrNo = 0                -- no error at the beginning

procedure proc1()
   if <some error> then
      ErrNo = 27
   elsif <another error> then
      ErrNo = 5
   else
      ErrNo = 0
   end if
end procedure

procedure proc2()
   if <some error> then
      ErrNo = 3
   elsif <another error> then
      ErrNo = 22
   else
      ErrNo = 0
   end if
end procedure

proc1()
proc2()

I think here is a problem, when there is an error in proc1(), and no
error in proc2(). proc2() then will clear the variable 'ErrNo', and the
information about the error in proc1() is lost.

-- Implementation #2
integer ErrNo
ErrNo = 0                -- no error at the beginning

procedure proc1()
   if <some error> then
      ErrNo = 27
   elsif <another error> then
      ErrNo = 5
   end if
end procedure

procedure proc2()
   if <some error> then
      ErrNo = 3
   elsif <another error> then
      ErrNo = 22
   end if
end procedure

proc1()
proc2()

The same as above, but without
   else ErrNo = 0.
In this case, 'ErrNo' never will be cleared, and it always holds the
number of the last error that occured.

I can see that implementation #1 is not a good idea, but what about
implementation #2?

Regards,
   Juergen