Re: [Netrexx-develop] address with stream

[René J. <rvj...@xs...>]

Yes, I think it is true that we don’t want to have to wrap address statements in exception handlers. Indeed maybe catching them and showing error messages and (high) returncodes is a better alternative. Or do we want some kind of event signalled - you only see that when you subscribe to it, and it just returns when nobody subscribed to it. That would look a lot like ‘signal on x’.

René.

> On 6 Mar 2022, at 15:16, Marc Remes <re...@gm...> wrote:
> 
> 
> oorexx signals are different, if you don't want to bother with them, you can just ignored them.
> You can 'trap' errors such as "address 'bbash' 'bbash'" by signals, if you do not have a 'signal on error' the script just continues.
> But specifying non-readable/writable streams just plain exits the oorexx script, not trappable.
> 
> Throwing such exception implies that any method which uses the ADDRESS instruction needs to put it in its signallist if the exception is not catched. Do we want this? And what about 'classless' scripts?
> There is no other NetRexx instruction that throws exceptions, in fact method interpret in interface RxClauseParser has an empty signallist. Changing that is significant.
> 
> I'm much in favor of restoring previous behavior, i.e. catching the exceptions in RexxAddress, but clearly show them on stdout as '+++ Error: Exception occurred during ADDRESS invocation', and setting RC empty or as 'RC'.
> 
> The user anyway would need to check RC after execution, and if desired a NumberFormatException can be catched.
> 
> Marc
> 
> 
> On 3/6/22 13:25, Rony G. Flatscher wrote:n
>>> On 05.03.2022 17:48, René Jansen wrote:
>>> No, I thinks that is definitely suboptimal. Why don’t we throw a netrexx.lang.AddressEnvironmentException, that the user can catch if they want to?
>> Also cf. ooRexx 5.0' reference documentation in "rexxref.pdf", chapters "2.1 ADDRESS" and "11.
>> Conditions and Condition Traps", for the conditions "error" and "failure" w.r.t. problems while
>> executing a command. If seen helpful one could distinguish both conditions in a field of
>> AddressEnvironmentException.
>> ---rony
>>> 
>>>> On 5 Mar 2022, at 16:24, Marc Remes <re...@gm...> wrote:
>>>> 
>>>> 
>>>> The latest commit exits the NetRexx program when an exception is thrown during ADDRESS invocation.
>>>> Such exception can occur when the specified environment is not executable, or when a specified stream is unusable.
>>>> The exitcode is 9.
>>>> Note, "address bash 'nonexistingcommand'" will not exit, instead processing will complete and say 'command not found'.
>>>> 
>>>> Personally I don't find such hard exit optimal.
>>>> Another option is not to exit, and reset the special variable RC to undefined 'RC', where the calling user can find such exceptional condition.
>>>> Both options could be coded and controlled by a new ADDRESSEXIT option.
>>>> 
>>>> Your views?
>>>> 
>>>> This code now also always correctly handles stderr.
>>>> 
>>>> Marc
>> _______________________________________________
>> Netrexx-develop mailing list
>> Net...@li...
>> https://lists.sourceforge.net/lists/listinfo/netrexx-develop
> _______________________________________________
> Netrexx-develop mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netrexx-develop