CArchive BUG

Take a look at the following code. Can you see the problem? The code crashes and burns if the socket 'socketFile' is attached to has its terminating socket closed. If the MFC developers would have followed standard guidelines for exception handling, everything would be fine. RULE: Never throw exceptions from destructors.


bool sendObject(CObject* pObj)
{
	other code ...

	CArchive ar(&socketFile, CArchive::store);

	ar << pObj;
	ar.Flush();
	ar.Close();

	... other code
}

void someOtherFunction()
{
	MyObject obj;

	bool bSuccess = false;
	try
	{
		bSuccess = sendObject(&obj);
	}
	catch (CException* pEx)
	{
		pEx->Delete();
	}
}

The Scenario:

Archiving an object to a CSocketFile that may have had the terminating socket closed.

The Result:

If the terminating socket has been closed, calling Flush on the CArchive will raise an exception (so will calling Close). In the previous case, before the exception is handled, CArchive goes out of scope and its destructor calls Close. Close throws another exception and all hell breaks loose. Never throw exceptions from destructors.

You will need nested try / catch blocks ...


bool sendObject(CObject* pObj)
{
	other code ...

	CArchive ar(&socketFile, CArchive::store);

	try
	{
		ar << pObj;
		ar.Flush();
		ar.Close();
	}
	catch (CException* pEx)
	{
		pEx->Delete();
		return false;
	}

	... other code
}

someOtherFunction()
{
	MyObject obj;

	bool bSuccess = false;
	try
	{
		bSuccess = sendObject(&obj);
	}
	catch (CException* pEx)
	{
		pEx->Delete();
	}
}



Comments

  • CArchive and CsocketFile

    Posted by Legacy on 02/17/2004 12:00am

    Originally posted by: guzhenghong

    i an using CArchive with CSockFile.
    
    At client:
    Send 100 CObject 's to server
    At Server:
    Recieve the first CObject is TRUE;
    But there is error result next.
    vc++6.0 windows 2000 pro

    Reply
  • CArchive

    Posted by Legacy on 09/04/2002 12:00am

    Originally posted by: Sarah

    Do you know if there is an alternative to a CArchive in C#??

    Reply
  • CSocket in Debug vs. Release

    Posted by Legacy on 01/08/2002 12:00am

    Originally posted by: Kevin Goodman

    I've got a different problem. Debug ver. works fine. Release version accepts in WINOCC.CPP COleControlContainer::AttachControlSite call to pSite = (COleControlSite*)m_siteMap.GetValueAt(pWnd->m_hWnd);

    The odd thing is I place a break point here in the Debug ver. and it nevers gets hit. The other really strange thing is I don't have any AFX or OLE controls in the app.

    Any thoughts?

    Reply
  • Use correct techniques !

    Posted by Legacy on 06/14/2001 12:00am

    Originally posted by: Maxo

    Why did you catch exceptions from archive sooner than you've created CArchive object ?

    Reply
  • avoiding the problem by using abort ??

    Posted by Legacy on 01/08/2001 12:00am

    Originally posted by: matthias metzner

    the command abort doesn't throw an exception at closing the archive (but also doesn't flush the archive) - perhaps this is the MS response to the error?

    have nice days ...

    Reply
  • Thanks for the clue...

    Posted by Legacy on 02/15/1999 12:00am

    Originally posted by: Mike Smith

    I've been having this somewhat intermittent problem with MFC sockets, got a feeling that what you're saying could be the cause.

    Reply
  • If you are sure it's a bug

    Posted by Legacy on 02/13/1999 12:00am

    Originally posted by: Hans Wedemeyer

    If you are sure it's a bug why not submit it to MS, they used to have a
    reward program for the first person to submit a true bug. The reward used to be
    a free compiler upgrade at next release..

    regards
    Hans Wedemeyer

    Reply
Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Today's competitive marketplace requires the organization to frequently release and deploy applications at the pace of user demands, with reduced cost, risk, and increased quality. This book defines the basics of application release and deployment, and provides best practices for implementation with resources for a deeper dive. Inside you will find: The business and technical drivers behind automated application release and deployment. Evaluation guides for application release and deployment solutions. …

  • With JRebel, developers get to see their code changes immediately, fine-tune their code with incremental changes, debug, explore and deploy their code with ease (both locally and remotely), and ultimately spend more time coding instead of waiting for the dreaded application redeploy to finish. Every time a developer tests a code change it takes minutes to build and deploy the application. JRebel keeps the app server running at all times, so testing is instantaneous and interactive.

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds