Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Exceptions vs NaN/NaI



Any JVM method can return normally or with exception.
In the first case the result is the value of <expr> in the "return <expr>;" statement.
In the second case the result is the Exception object created in the "throw new <Exception subclass>(<args>);" statement. 

So I want to understand what is valid JVM binding of P1788 operation.
Either it must always produce results by "return" satement
or it may produce normal results by "return" statement and special results by "throw" satement ?

I agree with existance of NaI intervals, because they are decorated Emptys.
However, I have a resistance to include NaN into my ExtendedRational class.

Even if the P1788 requires that result of mid(Empty) is NaN ,
I will implement such result by "throw new ArithmeticException();" or by
"throw new NotANumberException();". Will this implementation be considered non-standard ?

  -Dima 

----- Исходное сообщение -----
От: j.d.pryce@xxxxxxxxxxxx
Кому: vincent@xxxxxxxxxx
Копия: stds-1788@xxxxxxxxxxxxxxxxx
Отправленные: Понедельник, 7 Май 2012 г 20:23:57 GMT +04:00 Абу-Даби, Маскат
Тема: Re: Exceptions vs NaN/NaI

P1788

On 18 Apr 2012, at 13:40, Vincent Lefevre wrote:
> Dmitry wrote:
>> There are a few common ways to signal a failure in programming anguages:
>> 1) Set a global/thread-local flag like "errno";
>> 2) Return specifal value like NaI or NaN;
>> 3) Throw a language exception (like in C++ or in Java).
>> 
>> As far as I understand, the draft of the standard recommends(requires) (2).
...
>> However, shouldn't the P1788 be flexible enough to allow
>> both level 2 operations that signal by (2)
>> and  level 2 operations that signal by (3) ?
> 
> I think that (2) should be mandatory, but (3) can be allowed if
> the user requests it ((3) is not possible in all languages).

Surely (3) is *allowed* as long as the standard doesn't forbid it, which I see no reason to do. Are you suggesting the standard should do something stronger than *allow*, e.g. *recommend* that implementations provide (3)?

John P