Going thorugh overflow function documentation. I found overflow has following as return values.
Return Value:
A value different than EOF (or traits::eof() for other traits) signals success.
If the function fails, either EOF (or traits::eof() for other traits) is returned or an exception is thrown.
source :"http://www.cplusplus.com/reference/iostream/streambuf/overflow/"
Can anyone please tell me in which sceanrios is overflow function going to through an exception?
Any help will be appreciated
Streambuf is abstraction for stream's underlying storage or communication channel. The overflow() function can fail for any reasons the storage or channel can fail. E.g. disk error for disk files, broken connection for sockets etc.
Although wilx detailed the fail (EOF) condition, the exception condition can be either one of these: http://www.aoc.nrao.edu/php/tjuerges/ALMA/STL/html-3.4.6/classstd_1_1exception.html (can you guess which one? :) -- but it should (obviously) be std::overflow_error if you're writing your own output stream or something.
In my problematic scenario it was faling because it was not jumping the next address(setp calls was incrementating by 0) so retrying to use the same memory region and was giving segmentation fault.
Related
Is there any convention for using std::feclearexcept? In the examples you usually see, this is called before an operation is executed that might trigger a floating point exception. This seems a safe thing to do.
But should you also call std::feclearexcept after you have detected and handled an error, so that the error state does not persist throughout the rest of the program's execution?
If you would always call std::feclearexcept before checking for floating point exceptions, and if you would always check all operations that could trigger such exceptions, then this would be redundant. But these are a lot of ifs and an unlikely situation in real software, at least from my experience.
Simlar in reasoning to (re-)setting errno only before you do a specific operation and intend to check errno afterwards.
There might be conditions under which errno, or the floating point exception flags, are set that you are not aware of. You don't know where exactly they happened or what they mean semantically. You are not equipped to handle a situation of "uh, there was an overflow somewhere in the past but I don't know what it means".
Thus, you reset errno / call std::feclearexcept right before you execute a specific operation where you want to know the exact result / error condition, and do know how to handle it.
Resetting the error flags after that operation serves no purpose.
My intuitive feeling is that the data is thrown away entirely. I cannot seem to find a source with which to verify this suspicion.
What happens to data inserted into an unopen stream? (eg. std::ofstream)
Is the data discarded? Perhaps it is stored in a buffer until the stream is opened? Perhaps something else?
In the standard "remarks" of all the file stream buffer methods that correspond to operations on the buffer it indicates that if is_open() == false, the function always fails. Failure is defined as returning traits_type::eof(). This special value is caught by higher-level IO functions which in turn set std::ios_base::badbit flag in the stream state.
If the output stream is in a fail state (eg.: not open) nothing happens to the stream - the request to output/buffer data is ignored entirely.
Note: If the exception std::ios_base::badbit is enabled, it will be thrown.
Is this a standard enforced behavior that when an exception is thrown
in a custom std::streambuf method (eg. xsgetn),
it is caught (some status bits are set) but not rethrown ?
Is there any method to alter this (or pass the error message without some
dirty tricks) ?
There is a general guarantee that things like operator<< and
operator>> will not raise an exception unless asked to. You
can ask it to by specifying the exception mask:
stream.exceptions( std::ios_base::badbit );
(You can specify any or all of the error conditions here, but
badbit is probably the only thing you'd ever want to.)
If this is set, and a streambuf function exits through an
exception, that exception will be rethrown.
Another possibility is to maintain information concerning the
error in the streambuf, with a function to extract it. Then,
when the client code detects an error, it can use
dynamic_cast<MyStreambuf*>( stream.rdbuf() ) to get the
derived streambuf, and call its member functions to get the
error information.
I want to use boost::asio but I don't want boost to throw exceptions, because in my environment exceptions must not be raised.
I've encountered BOOST_NO_EXCEPTIONS but the documentation says that callers of throw_exception can assume that this function never returns.
But how can a user supplied function not return? What replacement function would I need to insert here? Do I have to terminate the process in case boost code wants to throw an exception?
Well, what do you want to do on error condition? BOOST_NO_EXCEPTION does not magically make Boost source code use alternative mechanism of propagating error back to callers. So, you either print an error to stderr and die, or you longjmp all the way to the top -- leaking whatever resources the functions presently on the call stack might have allocated.
Either you terminate the process or you goto a something like a global error handler using longjmp which you've previously defined with setjmp.
You seemed to have misunderstood the meaning of BOOST_NO_EXCEPTIONS, it only gives you a chance to bailout in the way you desire in a consistent manner.
The execution has entered a state where it can no more proceed, that is when exception is thrown, so if the user defined throw_exception returns then it is logical to think that the behavior is undefined.
If a call to fread() returns 0 and ferror() indicates an error (vs. EOF), is it OK to retry the read or is it better to close and reopen the file?
I can't start over entirely -- the input file has been partially processed in a way that can't be undone (say I'm writing out a chunk at a time to a socket and, due to existing protocol, have no way of telling the remote end, "never mind, I need to start over").
I could fclose() and fopen() the file, fseek() past the data already processed, and continue the fread()-ing from there, but is all that necessary?
There's no "one size fits all" solution, since different errors can require different handling. Errors from fread() are unusual; if you're calling it correctly, an error may indicate a situation that has left the FILE* in a weird error state. In that case you're best off calling fclose(), fopen(), fseek() to get things back in a good state.
If you're coding for something that's happening, please mention the actual errors you're getting from ferror()...
You can give the clearerr function a look.
You can show the error to the user with perror() or strerror() and ask her is she wants to retry.
It's not mandatory for the implementation to provide such an error message, though. You should set errno to 0 before calling fread(); if it fails and errno is still 0 then no error information will be available.