OpenEuphoria

Re: Try/Catch

• Posted by dcuny Jan 01, 2015
• 6358 views

A bit more detail on Go's error handling in Euphoria.

In Euphoria, as soon as an error is reached, the code halts. End of game, that's it.

Let's imagine Euphoria with Go's error handling.

Returning multiple values would require some major changes to Euphoria, so (for the sake of discussion), let's imagine that it's essentially the same as BASIC, and the error result it returned in a global variable. So you could do something like:

... 
someRoutine(a, b, c) 
if error then 
   -- handle the error 
end if 

Now, if you didn't check for the error condition, Euphoria would happily ignore all errors. Since would break a code model that people currently depend on, you'd probably need something along the lines of BASIC's on error continue, which tells BASIC not to halt on errors. So let's imagine that there was a routine called on_error_continue(flag) which accepted a true/false value. So you could write:

-- a typed variable 
atom x = 0 
 
-- don't halt on errors 
on_error_continue(1) 
 
-- do something that causes an exception 
x = "assigning strings to atoms fails!" 
 
if error then 
   printf(1, "The error was %s\n", {error_text}) 
end if 

This would be more or less backward compatible. Is this what you had in mind?

For me, this is considerably less good than try/catch. The reason is perhaps a bit counter-intuitive: I don't know where my code is going to encounter an error. And in Euphoria, the error is likely to be an indexing error of some sort:

s1[i][j] = s2[k][j] 

So unless I check the condition of error after every operation, I've got a good chance of performing a couple more operations before I notice things have gone wonky.

With try/catch, my code immediately jumps to the catch clause before more things can go awry.

Now, you could argue that since Euphoria doesn't do pass by reference, data won't be corrupted until the return from the function. (Unless, of course, you're using global variables).

Go's defer is slick, but I think it would be a hard sell. Doing something like this doesn't really have an analog in Euphoria:

func f() { 
    defer func() { 
        if r := recover(); r != nil { 
            fmt.Println("Recovered in f", r) 
        } 
    }() 
    fmt.Println("Calling g.") 
    g(0) 
    fmt.Println("Returned normally from g.") 
} 

Here, you've got an anonymous function potentially being pushed onto the stack for execution on exit of func(). This is entirely unlike how Euphoria works.

Another example from Go:

func c() (i int) { 
    defer func() { i++ }() 
    return 1 
} 

The function c() will push an variable number of anonymous functions (only known at runtime) onto the defer stack to be executed on exit of c(). And the parameters to these functions are dynamically evaluated before they are pushed onto the defer stack.

It's very slick, but it would require major changes to Euphoria.

I can't see this happening. While it could be coded in the interpreted version, getting something similar for the C compiler is another matter.

- David