Error with ifstream and exceptions

[Ian Collins]

Contrary to the other posters in this thread, C++ exceptions cannot be
thrown from anywhere.

In short, a C++ exception can only result from an executed "throw"
statement or or a failed dynamic_cast<reference_type>. (IIRC, those
are the only two things.)

Which is what I meant by anywhere, anywhere the programmer chooses to
throw one, not just with a try block. I didn't mean that can appear out
of nowhere!

 

[Joshua Maurice]

Which is what I meant by anywhere, anywhere the programmer chooses to
throw one, not just with a try block.  I didn't mean that can appear out
of nowhere!

Perhaps not you, but other posters were much more vague and incorrect
on this subject. At least, the posts else-thread are sufficiently
vague that I was afraid that the OP who is apparently new to C++
programming might get the wrong idea.

Sorry for any offense taken - none intended.

 

[Ian Collins]

Sorry for any offense taken - none intended.

None taken.

 

[James Kanze]

in the following code I get an error message after the file is output. What
did I do wrong?

Basically, I think you've misunderstood how IO works.

#include <iostream>
#include <string>
#include <fstream>
using namespace std;

int main() {
ifstream fileIn;
fileIn.exceptions ( ifstream::failbit | ifstream::badbit );

You don't *ever* (well, almost never) want exceptions on failbit
in input. The normal idiom is to read a file until it
fails---the most frequent reason for failure is that you've
reached end of file.

try {
fileIn.open( "file" ); }
catch ( ifstream::failure e ) {
cout << "Error."; }

string line;
while ( getline( fileIn, line ) ) {

And when you've no more lines to read?

cout << line << endl;
}
fileIn.close();
return 0;
}

In practice, the only thing you'd ever use exceptions for with
IO is badbit, which should be set in case of a hardware problem
(disk read error, etc.).

 

[James Kanze]

I'm confused, too.

You should start by ignoring Paul. He's just our local troll;
he doesn't know anything about C++ or programming; he just gets
his kicks by insulting people who do.

Exceptions can be thrown everywhere, is that right? But what
is the purpose of the try block? Why isn't it enough to write
a catch block if the exceptions can be thrown in the try block
and outside the try block? (I know it's not valid to write
catch without try, it's just to understand how things work.)

A program, regardless of the language, does what you tell it to.
If you tell it to throw an exception, it will throw an
exception. If you're not in a try block, then the program will
abort with an error.

Also, larger programs are spread over a large number of modules,
and the compiler (or the IO stream library component) has no way
of knowing whether you are in a try block or not.

 

[James Kanze]

[...]

Exceptions can be thrown by the OS or from code, there are different types
of exceptions.

Not in C++. Of course, the system can do anything if you have
undefined behavior, but you don't usually get an exception
(unless you've used special compiler options, and the system
supports it).

Your try/catch block is looking for an exception to be thrown
by the OS on file.open but this doesn't happen. A C++ exception is thrown in
the while loop and this is not handled inside a try block.
I think any code that can possibly invoke a C++ throw( C++ Exception) must
be enclosed in a try block, but not 100% sure, try putting the while loop in
a try/catch block and see what happens.
.

C++ is not a toy language. The compiler cannot possibly know
(in the general case) whether the throw is in a try block or
not. If an exception is uncaught, C++ says that the program
must be terminated.

 

[James Kanze]

Just for the record, well written C++ programs don't use
exceptions for reporting an error when opening a file.

That's exactly what I want. I tried (see my first post), but
it didn't work.

[...]

I did, but there are many solutions that are considered bad
practice. I don't know yet how to do it the right way. What I
try seems a bit verbose to me.

The following does what I want (and is pretty short, too):

#include <iostream>
#include <string>
#include <fstream>
using namespace std;

int main() {
ifstream fileIn;
fileIn.open( "not_existent" );
if ( !fileIn )
cout << "Error." << endl;

Well, you probably don't want to continue trying to read the
file if you can't open it. But other than that, you're doing
fine. That's the normal C++ idiom.

string line;
while ( getline( fileIn, line ) ) {
cout << line << endl; }

fileIn.close();
return 0;
}

But I've read that this is C-like, not C++ and I should better
use exceptions to handle non-existent files.

Where did you read that? Using an exception to report an
inexistant file is very bad software engineering, and should
only be done if you have no other choice. Which isn't the case
in C++.

 

[James Kanze]

Marco wrote:

[...]

But here the open() functions is not likely to throw any exceptions of
the kind you try to catch. Open() returns NULL if it cannot open the
file (which is not considered exceptional).

The open function also sets failbit if it fails to open the
file, and he's explicitly asked for an exception if failbit is
set.

 

[Alf P. Steinbach /Usenet]

* James Kanze, on 08.02.2011 02:03:

Where did you read that? Using an exception to report an
inexistant file is very bad software engineering, and should
only be done if you have no other choice. Which isn't the case
in C++.

That's a very subjective opinion.

When done properly, it can yield more clear and maintainable code.

I think possibly you're assuming a false dichotomy, that it's either exception
or possibility of checking result of open attempt.

With that as (incorrect) assumption you'd have to choose the practically least evil.

But it isn't either/or, and it isn't necessary to force client code to do
needless check or force it to needlessly deal with an exception.


Cheers & hth.,

- Alf

 

[Ian Collins]

Where did you read that? Using an exception to report an
inexistant file is very bad software engineering, and should
only be done if you have no other choice. Which isn't the case
in C++.

Unless the absence of the file is an exceptional event!

 

[Paul]

Basically, I think you've misunderstood how IO works.



You don't *ever* (well, almost never) want exceptions on failbit

don't EVER? or almost never?

in input. The normal idiom is to read a file until it
fails---the most frequent reason for failure is that you've
reached end of file.

EOF is not a 'failure', it's not only expected but guaranteed to exist.

You try to encourage the OP to not use failbit but you are wrong to suggest
that this is the norm.
Even if it was the norm who gives a dam what the norm is , it doesn't mean
he needs to code this way.

And when you've no more lines to read?


In practice, the only thing you'd ever use exceptions for with
IO is badbit, which should be set in case of a hardware problem
(disk read error, etc.).

This may be your practise, I don't see what anyone can gain from ignoring
failbit errors.
Hundreds of online examples use badbit or failbit masks, they are not all
wrong.

 

[Paul]

You should start by ignoring Paul. He's just our local troll;
he doesn't know anything about C++ or programming; he just gets
his kicks by insulting people who do.

I certainly know more about C++ than you suggest.
It's idiots like you who act like you know it all but you often get things
wrong that need to be watched, at least I don't 'pretend' to know
everything.
You have made an unprovoked insult towards me here, yes I've insulted
arseholes like you in the past but it was justified insults.

A program, regardless of the language, does what you tell it to.
If you tell it to throw an exception, it will throw an
exception. If you're not in a try block, then the program will
abort with an error.

Also, larger programs are spread over a large number of modules,
and the compiler (or the IO stream library component) has no way
of knowing whether you are in a try block or not.

bullshit theories from a bullshitting bullshitter.

 

[Paul]

I'm confused, too. Exceptions can be thrown everywhere, is that right? But
what is the purpose of the try block? Why isn't it enough to write a catch
block if the exceptions can be thrown in the try block and outside the try
block? (I know it's not valid to write catch without try, it's just to
understand how things work.)

Contrary to the other posters in this thread, C++ exceptions cannot be
thrown from anywhere.
Are you narrowing the context to only exceptions thrown by C++ code.

I was talking about exceptions in general which could for example be thrown
by a memory access violation. This can happen almost anytime during a
programs execution.
The context of everywhere in this conversation was taken to mean inside and
outside the try block.
If you are going to be pedantic everywhere does not include 'under a rock on
Mars' here.

I would comment further but my newsreader is not indenting so snipped rest.
<snip>

 

[Paul]

[...]

Exceptions can be thrown by the OS or from code, there are different
types
of exceptions.

Not in C++.

Yes in C++.

Of course, the system can do anything if you have
undefined behavior, but you don't usually get an exception
(unless you've used special compiler options, and the system
supports it).

Yup the system can do whatever it wants, whenever it wants and wherever it
wants. whatever.

C++ is not a toy language.

Yes it is.

<snip>

 

[Juha Nieminen]

[...]

Exceptions can be thrown by the OS or from code, there are different
types
of exceptions.

Not in C++.

Yes in C++.

Could you please show us how with standard C++ you catch an exception
thrown by the operating system?

(There are system libraries to catch signals, but those are neither C++
nor standard.)

Yes it is.

Ah, it must be because you say so. Very convincing.

 

[Paul]

[...]
Exceptions can be thrown by the OS or from code, there are different
types
of exceptions.

Not in C++.

Yes in C++.

Could you please show us how with standard C++ you catch an exception
thrown by the operating system?

(There are system libraries to catch signals, but those are neither C++
nor standard.)

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.

Ah, it must be because you say so. Very convincing.

Yup.

 

[Ian Collins]

Are you narrowing the context to only exceptions thrown by C++ code.

That's because this is a C++ discussion.

I was talking about exceptions in general which could for example be
thrown by a memory access violation. This can happen almost anytime
during a programs execution.

In general? If the OS maps asynchronous events to exceptions, that is
an extension, not part of standard C++. Most platforms don't do it.

I would comment further but my newsreader is not indenting so snipped rest.
<snip>

Your understanding of news readers appears to match your understanding
of C++.

 

[Paul]

That's because this is a C++ discussion.

hardware exceptions can also be caught by C++ code.

In general? If the OS maps asynchronous events to exceptions, that is an
extension, not part of standard C++. Most platforms don't do it.

What do you mean it's not *standard* C++?
Maybe your idea of SEH isn't standard, but any examples I see uses standard
compliant C++ code.


You seem to be confused about the meaning of *standard* C++.
Do you mean:
a) Legal C++ code that is complaint with the C++ international standards?
b) standard as the english dictionary definiton 1. an accepted or approved
example of something against which others are judged or measured

Your understanding of news readers appears to match your understanding of
C++.

I checked all the settings and it simply doesnt work when replying to some
people's posts.

Ian I would like to remind you of the last time you raised an argument with
me about C++ standards how I humiliated you by proving your lack of
knowledge. Please don't make the same mistake again, as I am embarrassed for
you.

 

[Ian Collins]

hardware exceptions can also be caught by C++ code.

Only if the operating environment maps them to C++ exceptions. As I
said, most don't.

What do you mean it's not *standard* C++?

There is no standard method for mapping hardware generated asynchronous
events to exceptions.

Maybe your idea of SEH isn't standard, but any examples I see uses
standard compliant C++ code.

SEH is a windows extension.

 

[Paul]

Only if the operating environment maps them to C++ exceptions. As I said,
most don't.


There is no standard method for mapping hardware generated asynchronous
events to exceptions.


SEH is a windows extension.

Are you suggesting that because it is an OS extension that it is not valid
C++ code?
You seem to imply it's wrong to use these Exceptions, what exactly is the
point you are trying to make here?

BTW your selective snipping has not gone unnoticed.