Yeah, I like the simplicity of if(!exists(...)).<br><br>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<br>
<br>- tim<br><br><br><br><div class="gmail_quote">On Fri, Apr 1, 2011 at 11:34 PM, Ben Clifford <span dir="ltr"><<a href="mailto:benc@hawaga.org.uk">benc@hawaga.org.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
> Try/catch statements don't have a clean intepretation if you're trying to<br>
> follow the flow of data through the program.<br>
<br>
Right.<br>
<br>
I thought about this a bit before but it started getting all haskelly and<br>
something i didn't want to approach - as mike says its much more<br>
researchy.<br>
<br>
The main idea which I found most comfortable was Haskell's Either type.<br>
That can model something like exceptions but is more amenable to a<br>
dataflow style of programming.<br>
<br>
(although C implements something very restricted similar in the form of<br>
pointers which can be NULL, or when returning a return code that is in<br>
some range of values for an error and some other range of values for<br>
success)<br>
<br>
The way the haskell Either type works is that something which might "throw<br>
an exception" returns a value that is either an error object or a correct<br>
value object.<br>
<br>
So then you use an if or a case or anything else that can change behaviour<br>
based on data to change your flow.<br>
<br>
Imagine in C:<br>
<br>
   p = malloc(5);<br>
   if(p == NULL) {<br>
       /* catch-exception, but dataflow style - we don't have to look at p<br>
          right after the malloc. We can store it into a structure and<br>
          come back to it later to check.<br>
          unfortuantely, there is not enough space in p to represent<br>
          any richer kind of exception information other than "FAIL" */<br>
   } else {<br>
   {<br>
       /* no exception, and we have the correct value in p */<br>
   }<br>
<br>
In haskell, that looks like:<br>
     p = somefunc<br>
     case p of<br>
        Right d -> doSomethingWith d   -- somefunc succeeded and returned<br>
                                       -- us value d<br>
        Left ex -> handleError ex      -- somefunc failed and returned<br>
                                       -- value ex as the equivalnet of a<br>
                                       -- Java Exception object.<br>
<br>
Now it gets a bit awkward having to unwrap "Right d" after every such<br>
function call, and in that respect I think a syntax that looks more like<br>
try-catch is much easier to program with. However I think the right way to<br>
go is to define its semantics in terms of "dataflow" style exceptions<br>
above rather than control-flow.<br>
<br>
I think that's possible and would result in something that satisfies both<br>
the dataflow-purist camp and the "I like exception syntax" camp (both<br>
camps of which I'm in ;)<br>
<font color="#888888"><br>
--<br>
</font></blockquote></div><br>