I don't think I understand what should happen in an expression with multiple operations when we do this "J to trap the exception" thing.
Language design needs to be specified so it does something for all the cases, and any "trapping of exceptions" that I can think of introduces all sorts of complexities. If you do not want those complexities, I think you should not be attempting to trap those exceptions. It's incredibly easy to express contradictory specifications. Implementing them, however, tends to be a lot more difficult (and, generally speaking, involves serious compromises). Thanks, -- Raul On Thu, Sep 21, 2017 at 7:58 AM, Erling Hellenäs <[email protected]> wrote: > Hi all ! > > I guess in J that means you should be able to configure J to trap the > exceptions and give errors like I stated earlier in this discussion. It is > hard to see that this would be a bad idea or error prone. As I see it it is > necessary if you don't want to risk random results. > > I don't understand what you write about complex abstractions. I didn't plan > to write any complex abstractions. > > Cheers, > > Erling > > Den 2017-09-21 kl. 13:42, skrev Raul Miller: >> >> On Thu, Sep 21, 2017 at 7:25 AM, Erling Hellenäs >> <[email protected]> wrote: >>> >>> I think we should at least be able to optionally trap the exceptions. >> >> This is generally a bad idea (time consuming and problem prone), but >> you can do this in J with explicit code. >> >> Note also that you can build up arbitrarily complex abstractions and >> hide the complexity in a locale structure, if that's what you want to >> be doing. >> >> Thanks, >> > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
