OpenEuphoria

Re: Try/Catch

• Posted by dcuny Jan 04, 2015
• 6021 views

I think we need to be clear that there are three different things here:

• Error codes return from functions;
• Ensuring resources are properly cleaned up; and
• Handling exceptions

While they are related, they aren't the same thing.

Exception handling isn't the same as a routine returning an error code. That's a good thing, and I won't argue against it. But it's a different sort of discussion.

The issue of releasing resources is what finally is all about. The cited paper seems to be suggesting something along the lines of how Go handles resources, by pushing deferred cleanup onto a stack.

Conceptually, finally could be implemented in Euphoria without try/catch, by extending the function/procedure block to include the clause:

function foo() 
   object resource = -1 
 
   -- grab the resource 
   resource = request_resource() 
 
   -- do more stuff 
 
finally 
   if resource != -1 then 
      -- release resource 
   end if 
 
end function 

It feels a bit sloppy to put the cleanup in the finally block, but it does allow you multiple exits with the guarantee that the cleanup code gets called.

It's certainly possible to do something more clever - such as what Go does - while staying in the bounds of how Euphoria executes. Certainly, there are some interesting alternatives.

Things get a bit complex when it starts interacting with try/catch, but it's not an impossible situation to code for.

Hopefully this sort of things gets handled when the dtor of the object gets called, so it's a bit of an exception.

Except, of course, that Euphoria doesn't have proper dtors, which makes it interesting to try to wrap libraries like wxWidgets.

It's been suggested that a QBasic approach could be used. The advantage of try/catch is that the code jumps to the catch block as soon as an error is raised. This means that you don't have to litter your code with exceptions.

This isn't going to replace checking return codes from functions like open(). After all, these aren't exceptions.

- David