Re: [Bug-apl] Feature request: UNWIND-PROTECT-like feature

[David Lamkins]

You may be able to construct that in APL.

I'm on my phone now, so this is from memory and may be wrong: take a look at quad-EM (and maybe quad-EMX, although that may well be a Dyalog-ism); you should be able to capture the error information and rethrow using quad-ES.

On Apr 21, 2014 8:09 PM, "Elias Mårtenson" <address@hidden> wrote:

OK, I've tried ⎕EA and it's almost what's needed. However, once the left-hand side is executed, the error goes away. Of course I can do an ⎕ES to throw a new error, but the previous error information is gone at that time (especially the )MORE information that is very important).

Would it make sense to add a "rethrow" command that can be called in the handler to make sure that the original error is preserved?

Regards,

Elias

On 21 April 2014 23:28, Elias Mårtenson <address@hidden> wrote:

Interesting. I didn't know about that one. I will investigate it tomorrow. Thanks for the information.

Regards,
Elias

On 21 Apr 2014 23:27, "David B. Lamkins" <address@hidden> wrote:

On Mon, 2014-04-21 at 17:34 +0800, Elias Mårtenson wrote:
> We need a feature similar to the Common Lisp form UNWIND-PROTECT, or
> in Java: try/finally.
>
>
> For those who don't know, this form allows you to execute code after
> some code has been run, regardless of how the latter exits (return
> normally, exited with error, etc...)
>
>
> What I envision is something like this:
>
>
>     {2÷0} ⎕UnwindProtect {⎕←'hello'}
>
>
>
> This code would print "hello" even though the left-hand _expression_
> yielded an error.
>
>
> I'd also like to see some information regarding the nature of the exit
> (return value of the left-hand form or error information) passed along
> in ⍵ and ⍺ to the right-hand function.
>
>
> A construct like this is necessary to create safe forms for dealing
> with, for example, SQL transactions safely. It will also be needed in
> the file utility library that I will be writing.
>
>
> I could, of course, implement this as a native library but I feel this
> is a feature that belongs in the core (since it's so important).

See quad-EA (execute alternate). That does almost the same thing, except
that the order of arguments is reversed (in keeping with APL's
right-to-left flow) and the arguments are quoted rather than in lambdas.

I'm using quad-EA in the transaction wrapper in my component-file
implementation.