Visual C ++，std和getline（ifstream，string），EOF在std堆栈内引发并中断，这正常吗？

Question

I remember all the hassle it used to be processing strings and ensuring that a newline was or wasn't appended before EOF.

Now as my error references interop I am wondering if this is normal behaviour still or just an interop 'enhancement', here's my error:

A first chance exception of type 'System.Runtime.InteropServices.SEHException' occurred in blah.exe
An unhandled exception of type 'System.Runtime.InteropServices.SEHException' occurred in blah.exe

Additional information: External component has thrown an exception.

Not terribly helpful. If I must terminate with a new line that's cool but is the std library so far optimized that it can't handle the odd EOF?

I think it should at least throw an exception that unwinds the stack to find a handler or terminate, but the stack is still deeply inside the std:: functions. Is this just a feature of the debug flags in VS?

EDIT

    ifstream is("MyfileorSummat.txt");
    string line;
    while (getline(is, line)) { //But when is reads last line @#&#@, it breaks, in the middle of a chain of std calls.

Answer 1

I have no idea how the SEHException is related, but is your input in the format of:

std::istream& in;
std::string line;
while (std::getline(in, line)) {
    //stuff
}

That's the safest method for reading in line by line I've ever come across.

I think it should at least throw an exception that unwinds the stack to find a handler or terminate
§ 15.3 (From Feb 2011 C++ draft)

If no matching handler is found, the function std::terminate() is called; whether or not the stack is unwound before this call to std::terminate() is implementation-defined (15.5.1).

This means the debugger was right about to crash your entire program (probably without unwinding), but decided to be nice and break and show you what was happening first. You'll have to step through the stack to see exactly why Windows decided to throw an SEHException . According to some random web crawling, an SEH can be fired by the standard library when you access unallocated memory, dereference NULL pointers, run out of memory, or other situations. You'll also want to try to look at the members of the SEHException object, to see what the status and message are.