Re: Try/Catch
- Posted by jimcbrown (admin) Jan 11, 2015
- 5441 views
Handling exceptions can be done in a more high-level way, which is suitable to the overall usage of Euphoria.
I'm curious. How do you suggest these exceptions he handled?
I'm assuming that anything that ends up halting Euphoria is an exception.
Perhaps that should be changed.
I can see routines returning error codes, and in many cases they already do.
Not all do, however. Remember "sequence found inside character string" for puts() and somesuch?
But a much more typical case is an indexing error, such as:
x = s[length(s)+1]
What innovation would you suggest for this? Because of the way indexing and slicing are done, I don't see how and error code can be returned, and from what.
The only reasonable solution I can come up with (outside of pcode or try/catch that is) - add a special index_crash_routine() for this case, and if a handler is defined, call it with the sequence and the index and let it figure out what to return (or alternatively to crash). If no handler is defined, crash. But then you'd probably have to come up with similiar functional_crash_routine()s for each category of errors that can't be handled by a return code.
The easy way out would be to set a global errno and leave the value of x unchanged, but I think it's obvious why no wants to do this.
Looking at the example bugmagnet came up with, that framework would throw a Throwable: https://github.com/andresteingress/gcontracts/blob/master/gcontracts-core/src/main/java/org/gcontracts/PreconditionViolation.java
At least in bugmagnet's example, Design by Contract is used as part of the fail fast philosophy. Which, as I've said before, may be fine in development but not so much in production.
David,
Index exceptions can be trapped using innovative 'Specifications' technique - which is able to return error codes in a clear, simple and very high-level way.
Using ... Throwables ....
The exception occurs only at the low level implementation of 'Specifications' - at the high level only error codes are returned.
Not in bugmagnet's example, which states that the two pieces of java code are identical:
<pre> def start() { if (started) { throw new AssertionError("Rocket already started!") } def oldSpeed = speed speed += 10 started = true if (!(started speed - oldSpeed > 0)) throw new AssertionError("Rocket not }
@Requires({ !started }) @Ensures({ started speed > 0 }) def start() { speed += 10 started = true } </pre>
In most cases testing the unsafe code using if...then is suffice.
Right, but that brings us back to the earlier discussion about third party libraries.
'Specifications' may be applied to a whole module, or a single routine - depends on the implementation.
In Bugmagnet's example (gcontracts), it appears to be necessary for this to be done on each routine individually.
Even if you could specify a specification for an entire module, you would almost always want to add individual specifications to each routine anyways...
