I have to implement an async HTTP GET in C++ and we have to be able to submit the app to the Windows 8 Store.
My problem is the following:
I've found a suitable Sample code which implements an HttpRequest class http://code.msdn.microsoft.com/windowsapps/HttpClient-sample-55700664
This example works if the URI is correct but throws an exception if the URI points to an invalid / non existing place (like: www.google22.com). This would be fine if I could catch the exception but I cannot figure it out how or where should I catch it.
Now some code.
This is the call to the async, concurrency::task based method which throws the exception:
try {
...
Web::HttpRequest httpRequest;
httpRequest.GetAsync(uri, cancellationTokenSource.get_token())
.then( [] (concurrency::task<std::wstring> response)
{
try {
response.get();
}
catch( ... ) {
int i = 1;
}
return response;
})
...
} catch ( ... ) {
...
}
And this is the relevant segment of the GetAsync method (the end of the method):
// Return a task that completes when the HTTP operation completes.
// We pass the callback to the continuation because the lifetime of the
// callback must exceed the operation to ensure that cancellation
// works correctly.
return completionTask.then([this, stringCallback](tuple<HRESULT, wstring> resultTuple)
{
// If the GET operation failed, throw an Exception.
CheckHResult(std::get<0>(resultTuple));
statusCode = stringCallback->GetStatusCode();
reasonPhrase = stringCallback->GetReasonPhrase();
return std::get<1>(resultTuple);
});
The CheckHResult line throws the exception, it's code:
inline void CheckHResult(HRESULT hResult)
{
if (hResult == E_ABORT)
{
concurrency::cancel_current_task();
}
else if (FAILED(hResult))
{
throw Platform::Exception::CreateException(hResult);
}
}
I have a try-catch around the GetAsync call and I also have a try-catch in the .then continuation lambda.
In the relevant Microsoft documentation ( http://msdn.microsoft.com/en-us/library/windows/apps/hh780559.aspx ) it states that exceptions thrown by a task should be catchable in the next task in the chain but somehow it doesn't work in my case. Additionally not even the try-catch around the whole call catches the exception, it just slips through everything...
Anyone had this problem? I think I've tried everything stated in the official documentations but it still lets the exception go berserk and crash the app. What do I miss?
EDIT:
I've modified the code to do nothing else but exception handling and it still doesn't catch the exception thrown by the task in .GetAsync
Cleaned-up code:
try
{
Windows::Foundation::Uri^ uri;
uri = ref new Windows::Foundation::Uri( uri_string_to_fetch );
concurrency::cancellation_token_source cancellationTokenSource = concurrency::cancellation_token_source();
Web::HttpRequest httpRequest;
OutputDebugString( L"Start to fetch the uri...\n" );
httpRequest.GetAsync(uri, cancellationTokenSource.get_token())
.then([](concurrency::task<std::wstring> response)
{
try {
response.get();
}
catch( ... ) {
OutputDebugString(L"unknown Exception");
}
})
.then([](concurrency::task<void> t)
{
try {
t.get();
// .get() didn't throw, so we succeeded.
}
catch (Platform::Exception^ e) {
// handle error
OutputDebugString(L"Platform::Exception");
}
catch (...) {
OutputDebugString(L"unknown Exception");
}
});
}
catch (Platform::Exception^ ex) {
OutputDebugString(L"Platform::Exception");
errorCallback(-1);
}
catch ( ... ) {
OutputDebugString(L"unknown Exception");
errorCallback(-2);
}
This still gives me a crash with the exception message: First-chance exception at 0x75644B32 in App1.exe: Microsoft C++ exception: Platform::COMException ^ at memory location 0x077EEC28. HRESULT:0x800C0005
Additionally when I put some breakpoints in the code it shows that the exception slips through everything before the first .then would be called. I've put breakpoints in these locations (in the simplified / cleaned up code):
before the GetAsync call
into the GetAsync, to the CheckHResult(std::get<0>(resultTuple)); line which throws the exception
into every try and catch case / block
Order of execution, tested with breakpoints:
before the GetAsync call [OK]
in the GetAsync, the line which will throw the exception [OK]
now the app crashes, slips through every try-catch, continue
now the line in the first .then gets called, in it's try block
another app level exceptions not catched by any catch block
now the first .then's catch block
second .then method's try block
and nothing more, the second .then's catch doesn't even catch any exception
And the printed debug logs, in order:
- Start to fetch the uri...
- First-chance exception at 0x75644B32 in App1.exe: Microsoft C++ exception: Platform::COMException ^ at memory location 0x082FEEF0. HRESULT:0x800C0005
- First-chance exception at 0x75644B32 in App1.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000.
- First-chance exception at 0x75644B32 in App1.exe: Microsoft C++ exception: Platform::COMException ^ at memory location 0x082FE670. HRESULT:0x800C0005
- First-chance exception at 0x75644B32 in App1.exe: Microsoft C++ exception: Platform::COMException ^ at memory location 0x082FDD88. HRESULT:0x800C0005
- unknown Exception
What is happening??
In the Concurrency Runtime any unhandled exception that occurs during the execution of a task is deferred for later observation. In this way, you could add a task based continuation at the end of the chain and handle errors there.
Something like this:
httpRequest.GetAsync(uri, cancellationTokenSource.get_token())
.then([](concurrency::task<std::wstring> response)
{
try {
response.get();
}
catch( ... ) {
int i = 1;
}
return response;
})
.then([](concurrency::task<void> t)
{
try {
t.get();
// .get() didn't throw, so we succeeded.
}
catch (Platform::Exception::CreateException^ e) {
// handle error
}
});
The call to .get triggers any exceptions that were raised in the task chain (if any).
For more details you can read Exception Handling in the Concurrency Runtime.
This related thread may have a clue:
Visual C++ Unmanaged Code: Use /EHa or /EHsc for C++ exceptions?
If you want to catch all the asynch exceptions you can try to set your Configuration Properties-> C/C++ -> Code Generation property to "Yes with SEH exceptions (/EHa)"
Related
In C++, why would you want to rethrow an exception. Why not let the current catch block handle the exception. For what reasons would you rethrow an exception to another try/catch block?
An exception is thrown when a function cannot meet its contract (what it promises the caller it will do). When a function calls another function that throws an exception, there are four main approaches to how it might respond:
Catch the exception and handle it. This should only be done if the function is able to meet its contract despite the exception being thrown. If it catches the exception but fails to meet its contract, it is hiding a problem from the calling code.
Allow the exception to propagate. This should be done if the exception cannot be handled by this function (that is, the function is unable to meet its contract because the exception has been thrown), and if the exception exposes the appropriate information to the calling code.
Catch the exception, do some clean-up and/or add extra info, and rethrow it. This should be done if the exception cannot be handled by this function, but it needs to do some cleaning up before propagating it. It can also provide extra information to help with handling/debugging the exception (I often think of the programmer as the very last exception handler).
Catch the exception and throw a different exception (perhaps wrapping the original). This should be done if the exception cannot be handled by this function, but a different exception better expresses the problem to the calling code.
Why not let the current catch block handle the exception. For what reasons would you rethrow an exception to another try/catch block?
The idea behind exceptions is that you throw them at the error site and handle them down the stack, where you have enough information to handle the error.
Conversely, there are cases when you must do something in case of an error, but still don't know how to handle the error (this is the case when you rethrow).
Example:
void connect_and_notify(int connection_data)
{
try
{
create_network_connection(connection_data); // defined somewhere else
notify("connection open"); // same (notify event listeners)
}
catch(const std::runtime_error&)
{
notify("connection failed");
throw;
}
}
Client code:
void terminal_app_controller()
{
try
{
connect_and_notify(1);
}
catch(const std::runtime_error& err)
{
std::cerr << "Connection failed;\n";
exit(1); // this is usually bad bad code but whatever
}
}
void ongoing_server_controller()
{
bool connected = false;
int connection = 1;
while(!connected)
{
try
{
connect_and_notify(1);
connected = true;
}
catch(const std::runtime_error&)
{
connection++;
}
}
}
In the two usage scenarios, the error is handled differently (connect_and_notify has no way of knowing that, but still, on a failed connection it must notify listeners).
Each function has a different policy to handle the exception and this means different catch blocks.
I very much dislike anything like
catch (std::exception&) {
... // do some cleanup
throw;
}
RAII is the correct solution to that problem. Even:
catch (std::exception&) {
... // do some logging here
throw;
}
can be handled with RAII, although it is less intuitive.
BUT - where I have rethrown is any situation where 3rd-part (or vendor-supplied) code throws "generic" exceptions with state. For example, when logging telematics messages to a database, I know that I often receive duplicate copies of the same message. Each message has a unique ID - so a primary key violation in my DB is an "innocent" error that should be silently ignored.
Unfortunately, the DB framework we use doesn't throw a specific exception for PK violations - so we need to catch the generic dbexception and check what its reason code is to decide what to do. Hence:
catch (db::exception& e) {
if (e.reason != db::exception::reason::pk_violation)
throw;
}
Also, piwi mentioned internal state. An example would be
for (;;) {
try {
...
}
catch (some_exception& e) {
if (retry_count > 3)
throw;
}
}
Remember: If you are going to rethrow, always catch by reference to avoid slicing the exception object. (You should usually catch by ref anyway, but it is even more important when rethrowing)
In this case, I have want to perform some actions based on the exception thrown and then re-throw the exception. Is this recommended - My aim is to do some work based on the exception thrown and rethrow it and have the application crash and generate dump that have the call stack in the exception.
class Foo
{
public:
void HandleException(const std::exception& ex)
{
// Log, report some metrics
throw;
}
void Work(//Some inputs)
{
try
{
// trying doing some work
}
catch (const std::exception& ex)
{
// This is really an exceptional situation, and the exception should be thrown which
// cause the exe to abort and create dump.
// Intention is to preserve call stack and have it in dump.
HandleException(ex);
}
}
}
Let me add another note to the question: When I have HandleException as a lambda function, throw in the lambda causes exception. Do I need to capture some state and how do I do that ?
When you catch an exception you have two options:
Achieve the original goal (contract) in some way, e.g. by retrying.
Report failure by throwing.
Rethrowing the original exception is one way to implement the second bullet point.
Yes that is valid. BUT it is also dangerous.
If you call throw; with no parameters and there is no exception currently in flight this will result in a call to std::terminate(). The problem with your current code is that anybody can call the function even when they are not in a catch block (which would result in termination).
So you may want to validate that an exception is propogating:
void HandleException(const std::exception& ex)
{
// Log, report some metrics
if (std::uncaught_exception()) {
throw;
}
// Maybe put an else here.
}
Also worth reading: GotW #47: Uncaught Exceptions
I've the following piece of code
try
{
// Vector creation in shared memory. The shm must exist.
m_pxShm = new managed_shared_memory(open_only, pcShmName);
m_pxShm->construct<T>(pcVecName)[iSize](); // THROW EXCEPTION <==
m_xVectorPair = m_pxShm->find<T>(pcVecName);
if (0 == m_xVectorPair.first)
{
throw std::exception();
}
}
catch (std::exception)
{
throw SharedMemoryVectorBadAllocException();
}
The SharedMemoryVectorBadAllocException use std::exception as base class. When I run this piece of code, the line with the 'construct' method throws an exception (because I create a vector bigger than shared memory). But the thrown exception is not handled, and the application crashes. Even if I debug it, line by line, the exception is not handled by the catch statement. I've tried to use as catch argument std::exception, interprocess_exception, ... and so on, without success. How can I handle the exception ? I'm using Visual studio 2010.
Hya advance users of SO,
First of all I am new to C++, so pardon me if I don't make myself clear asking question. I've seen a example of exception handling, but couldn't figure out what's happening here :(
http://codepaste.net/zqsrnj
or
enum ErrorCode {…}; // this is exception class
ErrorCode dispatcher() {
try {
throw; // what is thrown here in function?, if rethrow what is rethrown?
}
catch (std::bad_alloc&) {
return ErrorCode_OutOfMemory;
}
catch (std::logic_error&) {
return ErrorCode_LogicError;
}
catch (myownstdexcderivedclass&) {
return ErrorCode_42;
}
catch(...) { // this will handle the above throw in try block of dispatcher
return ErrorCode_UnknownWeWillAllDie;
}
}
ErrorCode apifunc() {
try {
// foo() might throw anything
foo();
}
catch(...) {
// dispatcher rethrows the exception and does fine-grained handling
return dispatcher();
}
return ErrorCode_Fine; //
}
ErrorCode apifunc2() {
try {
// bar() might throw anything
bar();
}
catch(...) {
return dispatcher();
}
return ErrorCode_Fine;
}
Can anyone explain this line by line or overall what's happening here, how control is flowing? Any help is very much appreciated, so thanks a lot.
apifunc() and apifunc2() translate exceptions into error codes, using the dispatcher() function.
Basically, what happens is as follows:
apifunc() (and similarly apifunc2()) attempts to call a function foo(). If foo() throws an exception, then the catch block will call dispatcher() to get the error code corresponding to the exception, and then returns that error code. If foo() doesn't throw, apifunc() returns ErrorCode_Fine indicating no error.
dispatcher() works by re-throwing the last exception thrown, i.e. the one foo() threw. dispatcher() then checks which exception was thrown using the catch blocks, and returns the correct error code. For example, if foo() threw std::bad_alloc, then that catch-block will be executed and return ErrorCode_OutOfMemory;.
Why would someone do this?
Exceptions are not necessarily binary compatible across different compilations (compilers, compiler flags, and so on), so translating exceptions to error codes is more portable across module boundaries.
When foo() throws an exception during its execution, the exception is caught in the apifunc() wrapper whose catch clause invoke the dispatcher() method. There the "current" exception is rethrown (that's the empty throw statement in the dispatcher() method) and caught again. Then the different catch clauses (bad_alloc, logic_error, myownstdexcderivedclass ... returns a sepcific error code than will be returned to the outside world.
The last catch(...) clause ensures that no exception will ever be thrown to the callers of apifunc().
If I have a code like the following:
try {
doSomething();
} catch (...) {
noteError();
}
void noteError() {
try {
throw;
} catch (std::exception &err) {
std::cerr << "Note known error here: " << err.what();
} catch (...) {
std::cerr << "Note unknown error here.";
}
throw;
}
Will the original exceptions get thrown from both places inside the lower frame of noteError()?
Your original code was fine. You caught different exception types and called a function that would log a message and rethrow. The throw statement is not required to appear directly inside the corresponding catch block. If you call one of those "note" functions and you're not currently handling an exception, though, then your program will call terminate().
Your new code is also fine. It's OK to catch everything and then call another function that rethrows to go to a more specific handler. That's the exception dispatcher idiom described in the C++ FAQ. It looks a little peculiar to rethrow the exception after the dispatching block has finished, but if that same throw statement had occurred after noteError returned (inside the original catch block) instead of where it is now, then it would be perfectly ordinary; it's demonstrated in the standard, §15.1/6.
The wording in the standard (§15.1/2) is (emphasis mine):
When an exception is thrown, control is transferred to the nearest handler with a matching type (15.3); “nearest” means the handler for which the compound-statement, ctor-initializer, or function-body following the try keyword was most recently entered by the thread of control and not yet exited.
When has a try block "exited"? According to the grammar (§15/1), try blocks end with a sequence of handlers, so the block ends when the last handler ends. In other words:
try // <- start of try block
{
}
catch (whatever) // <- first handler
{
}
// ... more handlers
catch (whatever_again) // <- last handler
{
} // <- end of try block
So yes, your code is fine. When re-thrown, the nearest try block has a matching handler (namely catch (...)), so that handler is entered.