[Swift-devel] Re: saturday morning rambling about exceptions

[Michael Wilde]

----- Original Message -----
> Yeah, I like the simplicity of if(!exists(...)).

I do too, but Ben, I like the ideas you suggest of dataflow-based exception handling and think we should continue the discussion.

I think that the exists() use case is not one for exception handling. Rather, it raises other programming model issues related to both mapping and to the original make-like "virtual data" semantics of VDL: if a file doesnt exist you execute the function to create it. Maybe we can cleanly integrate this back into Swift in an optional manner (ie, it only happens when explicitly requested). On the other hand, maybe thats exactly what exists() will give us?  Dont know yet.

I think the exception handling mechanism is very useful to pursue for true exception conditions.  And there to, we have the issue of when should exceptions get handled transparently by the runtime system and when should the script be able to see them? Maybe, there, too, exception handling happens transparent unless the user sets explicit exception handling. We'd need to consider if this changes with a dataflow-based approach.

- Mike

> With try/catch I just think it would be difficult for the user to
> reason about what state things are in when an exception occurs and we
> end up in the catch block - it seems very nondeterministic which
> threads will be running and how much progress they will have made
> 
> - tim
> 
> 
> 
> 
> On Fri, Apr 1, 2011 at 11:34 PM, Ben Clifford < benc at hawaga.org.uk >
> wrote:
> 
> 
> 
> > Try/catch statements don't have a clean intepretation if you're
> > trying to
> > follow the flow of data through the program.
> 
> Right.
> 
> I thought about this a bit before but it started getting all haskelly
> and
> something i didn't want to approach - as mike says its much more
> researchy.
> 
> The main idea which I found most comfortable was Haskell's Either
> type.
> That can model something like exceptions but is more amenable to a
> dataflow style of programming.
> 
> (although C implements something very restricted similar in the form
> of
> pointers which can be NULL, or when returning a return code that is in
> some range of values for an error and some other range of values for
> success)
> 
> The way the haskell Either type works is that something which might
> "throw
> an exception" returns a value that is either an error object or a
> correct
> value object.
> 
> So then you use an if or a case or anything else that can change
> behaviour
> based on data to change your flow.
> 
> Imagine in C:
> 
> p = malloc(5);
> if(p == NULL) {
> /* catch-exception, but dataflow style - we don't have to look at p
> right after the malloc. We can store it into a structure and
> come back to it later to check.
> unfortuantely, there is not enough space in p to represent
> any richer kind of exception information other than "FAIL" */
> } else {
> {
> /* no exception, and we have the correct value in p */
> }
> 
> In haskell, that looks like:
> p = somefunc
> case p of
> Right d -> doSomethingWith d -- somefunc succeeded and returned
> -- us value d
> Left ex -> handleError ex -- somefunc failed and returned
> -- value ex as the equivalnet of a
> -- Java Exception object.
> 
> Now it gets a bit awkward having to unwrap "Right d" after every such
> function call, and in that respect I think a syntax that looks more
> like
> try-catch is much easier to program with. However I think the right
> way to
> go is to define its semantics in terms of "dataflow" style exceptions
> above rather than control-flow.
> 
> I think that's possible and would result in something that satisfies
> both
> the dataflow-purist camp and the "I like exception syntax" camp (both
> camps of which I'm in ;)
> 
> --
> 
> 
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel

-- 
Michael Wilde
Computation Institute, University of Chicago
Mathematics and Computer Science Division
Argonne National Laboratory