[nem-en] Re: Nemerle try catch behaviour

[Snaury]

Hmm... No, actually I think I'll be working on it some more. Moving
TryFault into Try maybe was also not a very wise idea. I'll be
rewriting it so that it won't be so much intrusive (so that only
TryWith will be deprecated by Try and the rest will stay as is). So,
I'll be posting new patch some time later.

On 7/30/06, Snaury <snaury at gmail.com> wrote:
> Hi everyone,
>
> I've been working on bug 695 (http://nemerle.org/bugs/view.php?id=695)
> today (forgot to set severity to major back when I reported it, and
> now I've changed it to major) and finally got a relatively working
> patch. This patch is big, intrusive (changes compiler parsetree and
> typetree, though parsetree is left compatible [for now] since
> otherwise boot won't compile it) and very experimental so I'd like
> someone to review it (because I'm almost sure that due to my lack of
> deep understanding of compiler I messed up with several things which
> might not surface themselves straight away).
>
> In short, it replaces Try fault/catch/finally node types with single
> Try node type which has a body and a list of Try cases (borrowed idea
> from how Match cases are organized). This way we can later generate
> single exception block with multiple catch blocks.
>
> As an additional feature catch now supports exception filters (i.e.
> conditions under which handler should be executed or skipped):
>
>   try {
>     // do something
>   } catch {
>     | e when (e.Message == "some message") => // do something
>   }
>
> This is not a full blown match (and I don't think full blown match is
> possible here, because variables binding really won't be easy between
> exception filter and handler, although..... if we can divide match and
> handler still retaining variable bindings in handler context then we
> could just br from filter to the endfilter and then reappear in
> handler with all the variable bindings... could someone do this?), but
> still may be useful for some people in some situations.
>
> There are, however, some problems I can see:
>
> 1) Macros. I don't understand it at all how quoted expressions are
> parsed. O.o Thus I don't get where expressions like <[ try $body catch
> { $exn is $exn_ty => $handler } ]> are parsed and how. The question
> is, due to change in parsetree, if expressions like <[ try $body catch
> {.. $cases} finally $fcase ]> would be possible or not? And where a
> relevant code should be added for this?
>
> 2) Perhaps I was too quick to get rid of TryFinally, because generated
> IL for finally clause has one more level of try anyway. The question
> is whether we should have Try node for catches only and TryFinally for
> finally, or as it is now a single Try node which has both catches and
> finallys? (having separate TryFinally actually has benefits, both in
> quoted expressions (<[ try $body catch {.. $cases} ]> then won't have
> finally case and <[ try $body finally $handler ]> would match
> TryFinally only) and in the mess I had to do with yields (detecting
> whether we have only one finally, or a finally in-between which is
> impossible but still, etc)). So what do you think?
>
> 3) I'm sure I messed up with either typing expected type of condition
> (hard coding <[ bool ]> is not the way I should go, isn't it?), or
> with WalkTry/Walk or with something else. I didn't understand what
> these things for, so just tried do it in a similar way. It won't break
> existing code, of course, but might allow something wrong in filters
> in catch. Could someone check to make sure the proper way for this?
>
> The patch can be downloaded here:
>
> http://snaury.googlepages.com/nemerle-experimental-try-catch-2006-07-29.patch
>
> As well as from attach if it passes thru to you.
>
>
>