Error with ifstream and exceptions

[James Kanze]

On 2011-02-08 James Kanze <[email protected]> wrote:

[...]

I use vim, too. That vim isn't capable of writing text files
without final newline makes me think of the reason. In general
vim isn't wrong. Maybe a text file has to have a final newline
by definition. But that's just a guess, I don't know.

Well, the reason vim can't do it is probably because vi
couldn't, and the reason vi couldn't is because it didn't
represent the end of line internally; the internal buffer was
a much older equivalent of std::vector<std::string>, with each
line in a separate string, without the newline (which was added
when writing the file).

The standard (C, but C++ defines its IO in terms of C) does say
that it is undefined behavior if the last character output to
a text file is not '\n'. But this wasn't specified until long
after vi was written.

 

[Joe Greer]

@n16g2000prc.googlegroups.com:

You didn't. Obviously, opinions as to when to use exceptions
vary, but in fact, my response was very oriented to you, the
context of your posting, and you're apparent programming level
in C++; Ian probably summed it up best with his response to me:
you don't use exceptions for a missing file unless the fact that
it is missing is somehow exceptional. (Which of course begs the
point as to what is exceptional, but in a short program which
reads a more or less random file, the fact that the file isn't
there could hardly be considered exceptional.)

The rule of thumb I tend to use for exceptions isn't whether or
not they
are "exceptional" it's answering the question "Do I want stack
unwinding
here?" Sometimes the answer depends on where I expect to handle
the
error. In the case of things like file io, I almost always
want to
handle the at the caller, so file io tends to use a return
value and not
an exception. Now... That isn't to say that after I have
cleaned up the
current mess, I wouldn't turn around a throw an exception to
unwind my
way to a higher level. My point is that exceptions are good
for
triggering stack unwinding. If that isn't what you want, then
use a
return code of some sort.

joe

 

[James Kanze]

@n16g2000prc.googlegroups.com:

The rule of thumb I tend to use for exceptions isn't whether
or not they are "exceptional" it's answering the question "Do
I want stack unwinding here?" Sometimes the answer depends on
where I expect to handle the error. In the case of things
like file io, I almost always want to handle the at the
caller, so file io tends to use a return value and not an
exception. Now... That isn't to say that after I have cleaned
up the current mess, I wouldn't turn around a throw an
exception to unwind my way to a higher level. My point is
that exceptions are good for triggering stack unwinding. If
that isn't what you want, then use a return code of some sort.

Where the error is to be handled is probably a more precise
criteria than "exceptional". Generally, there are three
possible reasons for using exceptions:

-- the error can't possibly be handled locally; some stack
unwinding will be necessary,

-- you're in a constructor, and you don't want the object to
exist if the error occurs, and

-- you're in some sort of overloaded operator, where return
codes are impossible.

Any time one of these is true, you should use an exception.

 

[Marco]

Where the error is to be handled is probably a more precise
criteria than "exceptional". Generally, there are three
possible reasons for using exceptions:

-- the error can't possibly be handled locally; some stack
unwinding will be necessary,

-- you're in a constructor, and you don't want the object to
exist if the error occurs, and

-- you're in some sort of overloaded operator, where return
codes are impossible.

Any time one of these is true, you should use an exception.

Thanks for the explanation.


Marco

 

[Juha Nieminen]

Why are they neither C++ not standard?
This code is valid C++ and standard compliant C++ code:

__try
{
// guarded body of code
}
__except (filter-expression)
{
// exception-handler block
}


The above code may be implementation specific but that does not mean it's
not C++ code, as you have ridiculously stated.

You don't seem to understand what "standard" means. It's that document
they published in 1998 (and revised in 2003).

"Implementation specific" extension means by definition non-standard.

 

[Paul]

You don't seem to understand what "standard" means. It's that document
they published in 1998 (and revised in 2003).

"Implementation specific" extension means by definition non-standard.

'That document' defines the language and to say something is non-standard
implies it does not not comply with the rules of the language, as defined in
the ISO document/s.

It does not make sense to say a piece of code is non standard, with your
inerpretation that 'standard' means that ISO document. This is like saying
'that code is not the ISO document'.

You can however say that code is not standard using the word 'standard' as
defined in the english language. Meaning something along the lines of 'it is
not of the norm'.

Additionally you say that *by definition* implementation specific code is
non standard well the standard I am looking at says:
"1.3.10 [defns.impl.defined]
implementation-defined behavior
behavior, for a well-formed program construct and correct data, that depends
on the implementation and
that each implementation documents"

Additionally the code itself *IS* standard code, it may invoke non standard
behaviour but the code complies with the rules of the ISO standard.

Lets say I make a function called myFunction. Are you saying this is non
standard because the behaviour is not defined in the ISO Document? In that
case almost all code is non standard in your mind, so what difference does
it make if it standard or non standard?

 

[Juha Nieminen]

'That document' defines the language and to say something is non-standard
implies it does not not comply with the rules of the language, as defined in
the ISO document/s.

It does not make sense to say a piece of code is non standard, with your
inerpretation that 'standard' means that ISO document. This is like saying
'that code is not the ISO document'.

"Non-standard" is basically a shortcut for "doesn't comply with the C++
standard", referring to the document. You are nitpicking about wording.

You can however say that code is not standard using the word 'standard' as
defined in the english language. Meaning something along the lines of 'it is
not of the norm'.

No. When talking about C++ in particular, "non-standard" specifically
refers to not complying with the official standard document. "Norm" would
imply some kind of informal agreement or custom.

Additionally you say that *by definition* implementation specific code is
non standard

No. What I said is that an implementation-specific *extension* is by
definition non-standard. Clearly something like "__try {...}" is such
an extension (unless you have a #define macro earlier in the code that
would substitute it for something else).

well the standard I am looking at says:
"1.3.10 [defns.impl.defined]
implementation-defined behavior
behavior, for a well-formed program construct and correct data, that depends
on the implementation and
that each implementation documents"

Implementation-defined behavior and an implementation-specific extension
are two different things. "__try {...}" is clearly of the former type.
It's not something that the standard defines, but leaves the behavior up
to the compiler. (Unless you can show me where "__try" is defined in the
standard. I might have missed it.)

Additionally the code itself *IS* standard code, it may invoke non standard
behaviour but the code complies with the rules of the ISO standard.

It conforms to the standard only if you have a preprocessor macro that
substitutes "__try" and "__catch" with something valid. All by themselves
they aren't defined by the standard.

They might compile with some compiler, but that doesn't make them
standard. In that case they would be an implementation-specific extension.

Lets say I make a function called myFunction. Are you saying this is non
standard because the behaviour is not defined in the ISO Document?

The standard clearly defines function declarations and how they are
written. Does the standard define the "__try {...} __catch {...}"
syntax?

By your logic you could write Haskell inside a C++ function, and
if the compiler has an extension that understands and compiles it, that
makes it "standard".

 

[Paul]

'That document' defines the language and to say something is non-standard
implies it does not not comply with the rules of the language, as defined
in
the ISO document/s.

It does not make sense to say a piece of code is non standard, with your
inerpretation that 'standard' means that ISO document. This is like
saying
'that code is not the ISO document'.

"Non-standard" is basically a shortcut for "doesn't comply with the C++
standard", referring to the document. You are nitpicking about wording.

You can however say that code is not standard using the word 'standard'
as
defined in the english language. Meaning something along the lines of 'it
is
not of the norm'.

No. When talking about C++ in particular, "non-standard" specifically
refers to not complying with the official standard document. "Norm" would
imply some kind of informal agreement or custom.

Additionally you say that *by definition* implementation specific code is
non standard

No. What I said is that an implementation-specific *extension* is by
definition non-standard. Clearly something like "__try {...}" is such
an extension (unless you have a #define macro earlier in the code that
would substitute it for something else).

well the standard I am looking at says:
"1.3.10 [defns.impl.defined]
implementation-defined behavior
behavior, for a well-formed program construct and correct data, that
depends
on the implementation and
that each implementation documents"

Implementation-defined behavior and an implementation-specific extension
are two different things. "__try {...}" is clearly of the former type.
It's not something that the standard defines, but leaves the behavior up
to the compiler. (Unless you can show me where "__try" is defined in the
standard. I might have missed it.)

Where is your proof that the standard condemns this code as non C++?
I posted a quote that show the standard endorses this and you say that this
is not implementation defined behaviour , but implementation extensions.
What crap. If the standard said something negative about impl-def-behavior
you wouldn't be saying that.

It conforms to the standard only if you have a preprocessor macro that
substitutes "__try" and "__catch" with something valid. All by themselves
they aren't defined by the standard.

They might compile with some compiler, but that doesn't make them
standard. In that case they would be an implementation-specific extension.

This is implementation defined behaviour and the standard endorses this.

If I have a random piece of steel pipe that is not specified in the ISO
standard for steel pipes. This does not mean that my pipe is not a piece of
steel pipe.
It is not a standard piece of pipe but it is nonetheless still a piece of
steel pipe.

Just becuase something is not standard does not automatically imply it is
sub-standard. And it certainly doesn't imply it is not what it is, in this
case the code is C++ code. You can't say this is not C++ code because it is
not defined in the standard.

The standard clearly defines function declarations and how they are
written. Does the standard define the "__try {...} __catch {...}"
syntax?

The standard doesnt define it becuase it is implementaion defined. This
doesn't mean it is wrong or that it's not C++.

By your logic you could write Haskell inside a C++ function, and
if the compiler has an extension that understands and compiles it, that
makes it "standard".

I'm not saying it is *standard* , I am quite clear that it is
implementation specific.
But so what if its not defined in the standard, this does not mean it is not
valid C++, and it certainly doesn't automatically imply it's sub-standard.

Your argument is that it is not defined in the C++ standard therefore it's
not C++. This is simply incorrect.
If this was the case there would be hundred of libraries and extensions in
the wild that were sub-standard, non-C++ code.

 

[Juha Nieminen]

Where is your proof that the standard condemns this code as non C++?

The standard doesn't need to go through every possible combination of
possible syntax errors and condemn them as "non C++".

If a syntax is not valid as defined by the standard, but still compiles,
it's by definition a non-standard extension in that specific compiler.

I posted a quote that show the standard endorses this and you say that this
is not implementation defined behaviour , but implementation extensions.
What crap. If the standard said something negative about impl-def-behavior
you wouldn't be saying that.

That paragraph makes no sense.

"Implementation-defined behavior" and "an implementation-speficic
extension" are two completely different and independent things. You
are committing a fallacy of equivocation.

For example, the value of "sizeof(int)" is implementation-defined.
"typeof(expression)" is an example of a compiler extension (in this case
a gcc extension). The former is standard-compliant, the latter isn't.

This is implementation defined behaviour and the standard endorses this.

"Implementation-defined behavior" and "implementation-specific
extension" are two completely different things.

I'm not saying it is *standard* , I am quite clear that it is
implementation specific.

You are not saying it's standard, but when I say it's not standard,
you object. You are making no sense.

But so what if its not defined in the standard, this does not mean it is not
valid C++, and it certainly doesn't automatically imply it's sub-standard.

So your definition of "valid C++" is that if some compiler accepts it,
it's "valid C++".

I suppose that makes, for example, Objective-C "valid C++" because gcc
can compile Objective-C inside C++ source code.

Of course don't expect eg. Visual C++ to support a program written like
that, but hey, it's still "valid C++".

Your argument is that it is not defined in the C++ standard therefore it's
not C++. This is simply incorrect.
If this was the case there would be hundred of libraries and extensions in
the wild that were sub-standard, non-C++ code.

If a library conforms to the specification of the C++ standard, then it
is standard-compliant (but not part of the C++ standard).

A compiler extension is by definition non-standard.

 

[Paul]

The standard doesn't need to go through every possible combination of
possible syntax errors and condemn them as "non C++".

If a syntax is not valid as defined by the standard, but still compiles,
it's by definition a non-standard extension in that specific compiler.


That paragraph makes no sense.

"Implementation-defined behavior" and "an implementation-speficic
extension" are two completely different and independent things. You
are committing a fallacy of equivocation.

For example, the value of "sizeof(int)" is implementation-defined.
"typeof(expression)" is an example of a compiler extension (in this case
a gcc extension). The former is standard-compliant, the latter isn't.


"Implementation-defined behavior" and "implementation-specific
extension" are two completely different things.


You are not saying it's standard, but when I say it's not standard,
you object. You are making no sense.

You loosely use the term non-standard to mean 2 different things:
1) Not defined in the C++ standard.
2) Not compliant with the C++ standard

If you want to get nitpicky about terms these 2 things do not mean the same.
You are being nitpicky about the term implementation specific yet use the
term non-standard very loosely to mean two different things. It is this
inconsistenty in your argument I object to.

So your definition of "valid C++" is that if some compiler accepts it,
it's "valid C++".

If its a well formed program that does not break the rules defined in the
standard why shouldn't it be valid C++?
Why should it be classified as invalid?

I suppose that makes, for example, Objective-C "valid C++" because gcc
can compile Objective-C inside C++ source code.

Of course don't expect eg. Visual C++ to support a program written like
that, but hey, it's still "valid C++".


If a library conforms to the specification of the C++ standard, then it
is standard-compliant (but not part of the C++ standard).

A compiler extension is by definition non-standard.

You can say the same for an implementaion specific extension as you did for
a library:
If an IS-extension conforms to the specification then it is standard
compliant, but not part of the standard.

You were clear in the above example of a library but now what do you mean,
do you mean it is not-complaint with the standard or it is not-defined by
the standard?

 

[Juha Nieminen]

You loosely use the term non-standard to mean 2 different things:
1) Not defined in the C++ standard.
2) Not compliant with the C++ standard

No, I'm using it with the second meaning.

"__try {...} __catch {...}" is not compliant with the C++ standard.

If its a well formed program that does not break the rules defined in the
standard why shouldn't it be valid C++?
Why should it be classified as invalid?

You claimed that "__try {...} __catch {...}" is valid C++ because some
compiler accepts it. Of course it isn't, because its meaning is not defined
in the standard, nor do all standard-compliant compilers support it.

You can say the same for an implementaion specific extension as you did for
a library:
If an IS-extension conforms to the specification then it is standard
compliant, but not part of the standard.

A library is not the same thing as a compiler-specific extension.

If a library is standard-conforming, you can compile it and code using
it using any standard-conforming C++ compiler. A compiler extension is
something that by definition is non-standard and code using it cannot be
compiled with other C++ compilers.

 

[Paul]

No, I'm using it with the second meaning.

"__try {...} __catch {...}" is not compliant with the C++ standard.

What exactly does it not comply with?

You claimed that "__try {...} __catch {...}" is valid C++ because some
compiler accepts it. Of course it isn't, because its meaning is not
defined
in the standard, nor do all standard-compliant compilers support it.

Here you use meaning one again( its not defined in the standard therefore
not valid).
I think this proves my point.

A library is not the same thing as a compiler-specific extension.

If a library is standard-conforming, you can compile it and code using
it using any standard-conforming C++ compiler.
A compiler extension is
something that by definition is non-standard and code using it cannot be
compiled with other C++ compilers.

Your say it's not standard complaint because it doesn't work on all systems
, but it wasn't designed to be used on other systems so its complete
nonsense to suggest it should work on them.
If someone created a MS specific library of functions that included SEH ,
this code would not *by definition* be non-compliant with the C++ standard.
And it certainly cannot be said it is not even C++.

Note: I haven't once said something was standard because a compiler accepts
it.