There are always potential problems with anything.

Specifically, though, if you wish to write code to do something, you
have the problem of defining what it is that you want to do that fits
with what you need to do.

And, if you add things in that you do not need to do, that results in
unneeded complexity.

So, for example, a question, in the context of this thread, is: why do
you need to represent values which you do not know how to represent?

But there are an incredibly large set of such questions and an
incredibly large set of potentially valid answers to each of them. And
*that* is the essence of the problem I was referring to.

Thanks,

-- 
Raul


On Thu, Sep 21, 2017 at 9:45 AM, Erling Hellenäs
<[email protected]> wrote:
> Hi all !
>
> You statements and your example below makes me think there are problems with
> exception handling.
>
> Den 2017-09-21 kl. 14:06, skrev Raul Miller:
> "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. "
>
> There is no problem with exception handling? It is then a possible solution
> to implement these compulsory IEEE float exceptions?
>
> Cheers,
>
> Erling
>
> -------- Vidarebefordrat meddelande --------
> Ämne:   Re: [Jprogramming] Overflow, underflow, floats
> Datum:  Thu, 21 Sep 2017 09:27:51 -0400
> Från:   Raul Miller <[email protected]>
> Svar till:      [email protected]
> Till:   Programming forum <[email protected]>
>
>
>
>
> I do not see any cases illustrated here where it does not work?
>
> What are you talking about?
>
> Thanks,
>
> --
> Raul
>
>
> On Thu, Sep 21, 2017 at 9:22 AM, Erling Hellenäs
> <[email protected]> wrote:
>>
>> Hi all !
>>
>> I tried the exception handling. It works sometimes. It does not always
>> work?
>> J can not give errors because the exception handling does not always work?
>> There is no way to fix it so we have to accept random results of our
>> programs instead of errors?
>>
>> p=: 3 1 0 2
>>
>> q=: 3 1 1 0
>>
>> A=: A. :: (!@#)
>>
>> A p
>>
>> 20
>>
>> A q
>>
>> 24
>>
>> A. q
>>
>> |index error
>>
>> | A.q
>>
>> a=: 3 : 0
>>
>> try.
>>
>> A. y
>>
>> catch.
>>
>> 'error'
>>
>> end.
>>
>> )
>>
>> a q
>>
>> error
>>
>>
>> Cheers,
>>
>> Erling
>>
>>
>> Den 2017-09-21 kl. 14:33, skrev Raul Miller:
>>>
>>>
>>> Sure, and, for example:
>>>
>>> typetrap=:4 :0
>>>    try.
>>>      x/y
>>>    catch.
>>>      'this is a trap'
>>>    end.
>>> )
>>>
>>>     1 typetrap 1
>>> this is a trap
>>>
>>> Or, if you want some other kind of result (or if you want to see valid
>>> arguments):
>>>
>>>     +`'' typetrap i.4
>>> 6
>>>
>>> No problem, right?
>>>
>>> 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
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to