C++ Exception
-
Hi, CString m_sProto; CString sProtocols="PROTOCOL"; m_sProto = sProtocols; <- This is throwing one exception. I know it is throwing one exception catch(...). But how to know the exception? Thanks, Kotesara
Hi. This is from the MSDN. CString::operator = const CString& operator =( const CString& stringSrc ); throw( CMemoryException ); const CString& operator =( TCHAR ch ); throw( CMemoryException ); const CString& operator =( const unsigned char* psz ); throw( CMemoryException ); const CString& operator =( LPCWSTR lpsz ); throw( CMemoryException ); const CString& operator =( LPCSTR lpsz ); throw( CMemoryException ); Remarks The CString assignment (=) operator reinitializes an existing CString object with new data. If the destination string (that is, the left side) is already large enough to store the new data, no new memory allocation is performed. You should be aware that memory exceptions may occur whenever you use the assignment operator because new storage is often allocated to hold the resulting CString object. Example The following example demonstrates the use of CString::operator =. // example for CString::operator = CString s1, s2; // Empty CString objects s1 = "cat"; // s1 = "cat" s2 = s1; // s1 and s2 each = "cat" s1 = "the " + s1; // Or expressions s1 = 'x'; // Or just individual characters And heres what it says about CMemoryException. A CMemoryException object represents an out-of-memory exception condition. No further qualification is necessary or possible. Memory exceptions are thrown automatically by new. If you write your own memory functions, using malloc, for example, then you are responsible for throwing memory exceptions. So your catch should be something like this try { // do the string stuff } catch(const CMemoryException e) { // do something with it } catch(...) { // just to catch any others that crop up. // make sure you do somehing drastic if anything appears // here because it SHOULD NOT HAPPEN. } Hope this helps. Pete
-
Hi, CString m_sProto; CString sProtocols="PROTOCOL"; m_sProto = sProtocols; <- This is throwing one exception. I know it is throwing one exception catch(...). But how to know the exception? Thanks, Kotesara
Hi, Try this one catch(CException e) //i'm not sure if is pointer of not { TCHAR szCause[MAX_PATH]; szCause[0]=0x00; e.GetErrorMessage(szCause,sizeof(szCause));// } But the best way is to read CopyConstructor help for CString because the exception types are defined there. Best regards, /REMUS
-
Hi. This is from the MSDN. CString::operator = const CString& operator =( const CString& stringSrc ); throw( CMemoryException ); const CString& operator =( TCHAR ch ); throw( CMemoryException ); const CString& operator =( const unsigned char* psz ); throw( CMemoryException ); const CString& operator =( LPCWSTR lpsz ); throw( CMemoryException ); const CString& operator =( LPCSTR lpsz ); throw( CMemoryException ); Remarks The CString assignment (=) operator reinitializes an existing CString object with new data. If the destination string (that is, the left side) is already large enough to store the new data, no new memory allocation is performed. You should be aware that memory exceptions may occur whenever you use the assignment operator because new storage is often allocated to hold the resulting CString object. Example The following example demonstrates the use of CString::operator =. // example for CString::operator = CString s1, s2; // Empty CString objects s1 = "cat"; // s1 = "cat" s2 = s1; // s1 and s2 each = "cat" s1 = "the " + s1; // Or expressions s1 = 'x'; // Or just individual characters And heres what it says about CMemoryException. A CMemoryException object represents an out-of-memory exception condition. No further qualification is necessary or possible. Memory exceptions are thrown automatically by new. If you write your own memory functions, using malloc, for example, then you are responsible for throwing memory exceptions. So your catch should be something like this try { // do the string stuff } catch(const CMemoryException e) { // do something with it } catch(...) { // just to catch any others that crop up. // make sure you do somehing drastic if anything appears // here because it SHOULD NOT HAPPEN. } Hope this helps. Pete
Pete, I agree with your reply, but have a pet peeve against the catch(...) construct, especially under VC. First, note that this code leaks:
try {
CException *e = new CException;
throw e;
}
catch(...) {
MessageBox ("Hello");
}because the pointer is lost - there's no way to call
CException->Delete(). (This leak problem is not true of all compilers, which just makes matters muddier from a portability standpoint) Secondly, processor traps such as access voilations and divide by zero are also caught by catch(...), and there is no way that I know of to distinguish them inside the catch block. Opinion: Catch what you expect might be thrown and can deal with, and leave the rest to the OS. -
Pete, I agree with your reply, but have a pet peeve against the catch(...) construct, especially under VC. First, note that this code leaks:
try {
CException *e = new CException;
throw e;
}
catch(...) {
MessageBox ("Hello");
}because the pointer is lost - there's no way to call
CException->Delete(). (This leak problem is not true of all compilers, which just makes matters muddier from a portability standpoint) Secondly, processor traps such as access voilations and divide by zero are also caught by catch(...), and there is no way that I know of to distinguish them inside the catch block. Opinion: Catch what you expect might be thrown and can deal with, and leave the rest to the OS.Hi. Yes, I personally never use the catch(...) because of the very things you mention in your post. I didn't like the fact that I couldn't do anything intelligent from within the catch(...) block. If you do catch an error in catch(...) you could just tell the user and then either carry on and hope for the best or just shut down app. Neither are optimal solutions. If anyone has any contributions to this I would be interesting in hearing it. Pete
-
Pete, I agree with your reply, but have a pet peeve against the catch(...) construct, especially under VC. First, note that this code leaks:
try {
CException *e = new CException;
throw e;
}
catch(...) {
MessageBox ("Hello");
}because the pointer is lost - there's no way to call
CException->Delete(). (This leak problem is not true of all compilers, which just makes matters muddier from a portability standpoint) Secondly, processor traps such as access voilations and divide by zero are also caught by catch(...), and there is no way that I know of to distinguish them inside the catch block. Opinion: Catch what you expect might be thrown and can deal with, and leave the rest to the OS.leave it to the OS? you mean the lovely "This application has performed an illegal operation" message box? ask the average user which is more important: leaking 30 bytes or preventing the app from crashing without warning. if i do a "catch(whatever w)", i always follow it with a catch(...). or, if i'm wrapping C code, or someone else's code, or around code that has the potential to jump out pf array bounds (like when you are filling a buffer that you didn't allocate). in fact, i often put a catch(...) around every major code section, just in case something gets by testing. i also make sure that i do something intelligent in the catch, like attempt to get into a safe state. the headaches that little construct can save are worth megabytes of leaked memory, to the average user. -c