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" <loke...@gmail.com> 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 <loke...@gmail.com> 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" <dlamk...@gmail.com> 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.
>>>
>>>
>>>
>
