Vincent,
I agree that the current text of the standard prescribes that
textToInteral(s) signals the UndefinedOperation exception in cases (b)-(d).
However, I (as programmer) think that it would be useful if
syntax error is signalled by one exception and semantic error (l > u) is
signalled by another exception. So I asked this question to the group
because it seemed to me that we overlooked this.
However, both Marco and you consider that
textToInterval(s) shall signal UndefinedOperation exception both on syntax and on semantic error
and there were no other opinions.
So I will not insist.
-Dima
----- Original Message -----
From: vincent@xxxxxxxxxx
To: stds-1788@xxxxxxxxxxxxxxxxx
Sent: Monday, March 16, 2015 4:36:21 PM GMT +04:00 Abu Dhabi / Muscat
Subject: Re: textToIntevsal(s) and exceptions
On 2015-03-14 01:55:32 -0700, Dmitry Nadezhin wrote:
I have a question while testing Marco's reference implementation.
There are three exceptions related to textToInterval(s) :
InvalidOperand when s doesn't represent Level 2 datum
The standard says: "When an input Level 3 object does not represent a
Level 2 datum, the result is implementation-defined. An implementation
shall provide means for the user to specify that an InvalidOperand
exception be signaled when this occurs."
If the input expects a string, I would say that this can happen when:
* the input is not a string (e.g. is a language that is not strongly
typed);
* the input has the right type "string" but the string is invalid
as a string (e.g. when UTF-8 encoding is expected but there's an
invalid UTF-8 sequence).
But I would say that this mainly depends on the implementation, which
would have the choice to decide whether a string is valid or not before
seeing it as a "valid operand" for textToInterval(s). By "valid operand"
I don't mean that it has a value, just that it is regarded as a valid
string.
UndefinedOperation when Level 1 value doesn't exist
PossiblyUndefinedOperation when implementation can't determine
whether a Level 1 value exists.
Which exception shall be signalled in the cases below:
a) s is a null pointer;
This is out of scope of the standard: a null pointer is a notion in
*some* languages. Other languages may handle strings without using
pointers.
Note that in C, a null pointer is not a string. When an API expects
a string, a null pointer typically yields undefined behavior.
Here, I would say that the best solution would either be an assertion
failure (typical solution) or an InvalidOperand exception (see above).
b) s has bad syntax like
s="[1,,2]";
This is a valid string (as a string). Thus it is UndefinedOperation
(except if there's an extension...).
c) s has correct syntax but violates some semantic rule
s="[-inf,-inf]";
d) s has correct syntax and passes semantic rules, but condition l <= u
surely fails
s="[2,1]";
I would say that (c) and (d) should be treated in the same way in the
set-based flavor. Anyway neither is regarded as a valid empty set,
i.e. there is no Level 1 value, except if there's an extension[*] or
we are in a specific flavor: (d) would be valid in a Kaucher flavor.
[*] I'm not sure whether this is allowed since the syntax is correct
but a rule is violated.
e) s has correct syntax and, but condition l <= u possibly fails
s="[1.000000000000000000001,0x1.00000000000001p0]".
Either no exceptions (if the implementation is able to decide that
l <= u) or PossiblyUndefinedOperation, which has been created for
this kind of problem.
I think that:
(a) and (b) signal InvalidOperand
Note: concerning InvalidOperand, this is "might".
I disagree for (b), in particular because all the characters of the
string are valid.
(d) signals UndefinedOperand
(e) may signal PossiblyUndefinedOperand
Yes.
but I am not sure about (c).
With my answers, it is necessarily like (b) and (d).
The question is not only
What does the current text of the standard prescribe ?
but also
What does a programmer expect ?
The programmer expects that valid strings with no Level 1 value
are handled correctly, thus giving UndefinedOperation (or possibly
PossiblyUndefinedOperation in some cases).
The main question is the behavior on invalid strings. IMHO, an
implementation should give an exception (I would say InvalidOperand,
which could yield an assertion failure or something like that) when
this can be detected in an efficient way. In some languages like C,
it may be impossible to detect (e.g. pointer to an invalid memory
area, but this typically ends up with a segmentation fault, which
is another kind of exception, here at the OS level).