From: Dragan Milenkovic on
On 07/17/2010 12:37 AM, Walter Bright wrote:
> Dragan Milenkovic wrote:
>> May I ask why are they constantly being called "non-recoverable"
>> exceptions, while in the same time they are used to recover
>> the process instead?
>
> They're non-recoverable in the sense that language guarantees may not
> hold if
> they are caught. For example, destructors may not have been called
> during stack
> unwinding. Function purity guarantees may have been violated.

But does this mean that resources are not freed and some lock might
not have been released? I wouldn't like to continue executing
under those circumstances. Someone mentioned earlier that they
would restart a connection, while Nick Maclaren (if I understood
correctly) states that the process termination is the only option,
and I agree. On non-embedded applications I would still prefer
abort() with a core dump; I don't have enough experience with
embedded applications to judge...

--
Dragan

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: joe on

"Stanley Friesen" <sarima(a)friesen.net> wrote in message news:pih046hqtdh3fqbqbeh92n4oppe7u1bl83(a)4ax.com...
> "joe" <jc1996(a)att.net> wrote:
>>Mathias Gaunard wrote:
>>> On Jul 6, 1:48 pm, "joe" <jc1...(a)att.net> wrote:
>>>> Andre Kaufmann wrote:
>>>>
>>>>> Agreed, C# and Java strings are not perfect, but better than C++
>>>>> standard strings regarding Unicode. I think C# has been influenced
>>>>> by Windows Unicode support.
>>>>
>>>> What is wrong with fixed-width Unicode (UCS-2 or UCS-4)?
>>>
>>> UCS-2 doesn't allow to represent all Unicode characters.
>>
>>Most application programs don't need them.
>
> True, but more do than one might suppose. A Web browser, for instance,
> should be able to handle the entire Unicode repertoire provided that
> suitable fonts are installed on the system.

The exceptional case should not taint the common case.

>>
>>> UCS-4 is a waste of memory.
>>>
>>> And more abstract characters, like graphemes, are not fixed-width
>>> anyway (think combining character sequences).
>>
>>Those, again (here), are the exception to the rule.
>
> I disagree, or at least this is only true in English.

That is what the parenthetical "here" alluded to: I only have a need for
English. For me, anything outside of that is an exceptional case.

BTW, I was censored again, but I asked Mathias in the censored post to
name one English grapheme that needed more than one codepoint, since he
indicated that there was such an animal.

> Even for German,
> the fact that the Web standard specifies NFD for transmission means any
> useful application would need to support combining characters (think
> umlauts).


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Mathias Gaunard on
On Jul 17, 1:27 am, Stanley Friesen <sar...(a)friesen.net> wrote:

> I disagree, or at least this is only true in English. Even for German,
> the fact that the Web standard specifies NFD for transmission means any
> useful application would need to support combining characters (think
> umlauts).

Really? XML specifies NFC IIRC.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: joe on
Jens Schmidt wrote:
> Stanley Friesen wrote:
>
>> I disagree, or at least this is only true in English. Even for
>> German, the fact that the Web standard specifies NFD for
>> transmission means any useful application would need to support
>> combining characters (think umlauts).
>
> For an example where more than one code point for one character can be
> used in English: résumé.

No, that is not correct. English does not have diacritics. Should one
chose to use them, for romantic reasons or whatever, is fine (have fun
typing that on your computer), but that is not English. It is someone's
idea of a composite language that combines French and English. The
English word is: 'resume', and what distinguishes it from the other
meaning of the literal text is the surrounding context, which surely will
be unambiguous. Please don't litter my nice clean language with
diddly-do-dads from other languages thank you.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: nmm1 on
In article <i1qo8u$dom$1(a)speranza.aioe.org>,
Dragan Milenkovic <dragan(a)plusplus.rs> wrote:
>On 07/17/2010 12:37 AM, Walter Bright wrote:
>>
>>> May I ask why are they constantly being called "non-recoverable"
>>> exceptions, while in the same time they are used to recover
>>> the process instead?
>>
>> They're non-recoverable in the sense that language guarantees may not
>> hold if
>> they are caught. For example, destructors may not have been called
>> during stack
>> unwinding. Function purity guarantees may have been violated.
>
>But does this mean that resources are not freed and some lock might
>not have been released? I wouldn't like to continue executing
>under those circumstances. Someone mentioned earlier that they
>would restart a connection, while Nick Maclaren (if I understood
>correctly) states that the process termination is the only option,
>and I agree. On non-embedded applications I would still prefer
>abort() with a core dump; I don't have enough experience with
>embedded applications to judge...

Yes, that's what I meant, and I agree with your position. I have
implemented non-recoverable exceptions (for C, under MVS), and
used signal handlers under Unix, and it just isn't practical to
continue execution. In a language that was designed to include
them, you could continue execution (with only the 'active' objects
at the time of the exception being flagged as potentially corrupted
and unusable), but C++ was not. Actually, I don't know of any that
were ....

Depending on the exact cause, Walter Bright's examples are not
all of the guarantees that may be invalidated. If a 'system call'
is interrupted by an exception (in modern usage, 'signal'), then
something may be left in an unclean state. I/O is the classic
example, but not the only one. Also, VERY few current run-time
systems are signal-safe, even when they claim to be, and that can
cause weird effects. It's not easy to get right.

So, while I agree with the proponents that they are potentially
useful, I agree with the opponents that the standard can't specify
any defined behaviour for them! Which is the current state with
signal handling ....


Regards,
Nick Maclaren.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]