C / C++ / MFC

Error Handling in Functions

29-Jul-02 0:30

Check this:
http://msdn.microsoft.com/msdnmag/issues/02/02/PE/PE.asp[^]

Tomasz Sowinski -- http://www.shooltz.com

- It's for protection
- Protection from what? Zee Germans?

Paul Watson28-Jul-02 22:37

28-Jul-02 22:37

What is "best practice" for error handling and reporting within a called function in C++?

e.g. the function normally returns a DataSet but obviously when an internal error occurs, you want to return some kind of error description so that the caller can handle it gracefully. How do I then return that error description without causing problems as the function is expected to return a DataSet?

ta

regards,
Paul Watson
Bluegrass
Cape Town, South Africa

The greatest thing you'll ever learn is just to love, and to be loved in return - Moulin Rouge

Alison Pentland wrote:
I now have an image of you in front of the mirror in the morning, wearing your knickers, socks and shoes trying to decided if they match!

Nish Nishant28-Jul-02 23:54

Nish Nishant

28-Jul-02 23:54

One of the arguments to the function can be passed by reference, probably an integer. Now when an error occurs assign the proper error code to this integer and return NULL.

Now in your callee code you can do this :-

if(SomeMethod(........,nErrCode))
{
    //success
}
else
{
    cout << "error code " << nErrCode;
}

Nish

Author of the romantic comedy

Summer Love and Some more Cricket [New Win]

Review by Shog⁹
Click here for review[NW]

Paul Watson29-Jul-02 1:21

29-Jul-02 1:21

Nishant S wrote:
Now when an error occurs assign the proper error code to this integer and return NULL.

Thanks Nish, will give that a bash too.

regards,
Paul Watson
Bluegrass
Cape Town, South Africa

The greatest thing you'll ever learn is just to love, and to be loved in return - Moulin Rouge

Alison Pentland wrote:
I now have an image of you in front of the mirror in the morning, wearing your knickers, socks and shoes trying to decided if they match!

Tomasz Sowinski29-Jul-02 1:03

29-Jul-02 1:03

Paul Watson wrote:
How do I then return that error description without causing problems as the function is expected to return a DataSet?

Throw some exception. Otherwise people who call your function (including yourself) will just ignore the error information.

Tomasz Sowinski -- http://www.shooltz.com

- It's for protection
- Protection from what? Zee Germans?

Paul Watson29-Jul-02 1:11

29-Jul-02 1:11

Tomasz Sowinski wrote:
Throw some exception. Otherwise people who call your function (including yourself) will just ignore the error information.

Good point Tomasz, thanks. I assume that I use the throw function in C++ for this.

Thanks Tomasz Smile | :)

regards,
Paul Watson
Bluegrass
Cape Town, South Africa

The greatest thing you'll ever learn is just to love, and to be loved in return - Moulin Rouge

Alison Pentland wrote:
I now have an image of you in front of the mirror in the morning, wearing your knickers, socks and shoes trying to decided if they match!

Mike Nordell29-Jul-02 1:45

Mike Nordell

29-Jul-02 1:45

Paul Watson wrote:
What is "best practice" for error handling and reporting within a called function in C++?

Throwing a (C++) exception.

Paul Watson29-Jul-02 1:49

29-Jul-02 1:49

Mike Nordell wrote:
Throwing a (C++) exception.

Thanks Mike, will give it a bash.

regards,
Paul Watson
Bluegrass
Cape Town, South Africa

The greatest thing you'll ever learn is just to love, and to be loved in return - Moulin Rouge

Alison Pentland wrote:
I now have an image of you in front of the mirror in the morning, wearing your knickers, socks and shoes trying to decided if they match!

Alexandru Savescu29-Jul-02 3:47

Alexandru Savescu

29-Jul-02 3:47

Well, it is nice to throw an exception. However, you must not throw an exception when a function should return false instead. Exception introduce some overhead (bigger exe, the stack gets unwound etc.). One should throw exceptions when something really unexpected happened, not when let's say the user pressed A when should have pressed B.

Best regards,
Alexandru Savescu

Paul Watson29-Jul-02 3:55

29-Jul-02 3:55

Alexpro wrote:
One should throw exceptions when something really unexpected happened, not when let's say the user pressed A when should have pressed B.

Ok now I am a touch confused.

Lets say I have this: A function which reads an XML file and returns it as a DataSet. However in some cases that XML file will not be there, and an exception will be raised. Should I then let the caller handle it via the exception thrown, or should I trap that exception, handle it. But then how do I return to the caller that no DataSet will be returned because XYZ error occured instead?

regards,
Paul Watson
Bluegrass
Cape Town, South Africa

The greatest thing you'll ever learn is just to love, and to be loved in return - Moulin Rouge

Alison Pentland wrote:
I now have an image of you in front of the mirror in the morning, wearing your knickers, socks and shoes trying to decided if they match!

Alexandru Savescu29-Jul-02 4:22

Alexandru Savescu

29-Jul-02 4:22

Well it depends (as always). If the function that reads the XML should perform some clean up then you must handle the exception in that function and somehow rethrow it or return NULL. Like this:

DataSet* MyReadXMLFunc()
{
  DataSet* ds = new DataSet("MyDataSet");
  try
  {
    ds.ReadXml ("C:\\Text.xml");
    ....
  }
  catch (Exception* e)
  {
   // here you must do some cleaning 
   ....
   
   // You can popup a message box
   MessageBox (this, e->Message);
   
   // you can return NULL
   return NULL;
  }
  return ds;
}

// In the caller
DataSet* a = MyReadXMLFunc();
if (a == NULL)
  // something bad happened

This was a possbility. However, I would do a second approach. Create a DataSet object in the caller function and pass it as a pointer or reference to the method that parses the file. Like this

  DataSet* ds = new DataSet ("MyDataSet");
  try
  {
    MyReadXMLFunc (ds); //<-- you pass a param here  -->
  }
  catch (Exception* e)
  {
    // it went wrong
  }

 // In the MyReadXMlFunc you do this
void MyReadXMLFunc (DataSet* ds)
{
  try
  {
    ds->ReadXml ("C:\\file.txt");
    .....
  }
  catch (Exception *e)
  {
    // you need to catch an exception only if you want to clean up somethind
    // oterwise the caller will catch it.

    // clean up and rethrow
    throw e;
  }
}

For further reading on DataSets you may find this article useful Smile | :)

.

Best regards,
Alexandru Savescu

Paul Watson29-Jul-02 7:19

29-Jul-02 7:19

Alexpro wrote:
This was a possbility. However, I would do a second approach. Create a DataSet object in the caller function and pass it as a pointer or reference to the method that parses the file. Like this

That is a good idea, thanks Alexandru. Hopefully I can fit some of this exception handling into my article Smile | :)

Tomasz Sowinski29-Jul-02 4:56

Flicker free drawing woes!!!

29-Jul-02 4:56

Paul Watson wrote:
Should I then let the caller handle it via the exception thrown, or should I trap that exception, handle it

If you decide to handle the exception, you're basically translating the exception to error code. Your client (caller of this function) will have to check for error code. And we all know that it's very easy to forget about this.

We have XXI century now, exceptions are bread and butter of C++; this also applies to this bastard MC++ Smile | :)

. And don't worry about performance overhead.

Tomasz Sowinski -- http://www.shooltz.com

- It's for protection
- Protection from what? Zee Germans?

alex.barylski28-Jul-02 21:52

alex.barylski

28-Jul-02 21:52

I managed to successfully do this before but I can't remember if it was under OnDrawItem or OnPaint.

Anyways heres what i've managed so far:

CDC* pDC = CDC::FromHandle(LpDIS->hDC);
	
// Declare variables used in flicker free drawing
CBitmap bit; 
CRect rect;
CDC dc;

GetClientRect(&rect);

CString buff = GetItemText(LpDIS->itemID, 0);

dc.CreateCompatibleDC(pDC);
bit.CreateCompatibleBitmap(pDC, rect.right, rect.bottom);
CBitmap* hOld = dc.SelectObject(&bit);

dc.FillSolidRect(rect, RGB(128,128,128));
dc.TextOut(LpDIS->rcItem.left, LpDIS->rcItem.top, buff);
						 	
pDC->BitBlt(0, 0, rect.right, rect.bottom, &dc, 0, 0, SRCCOPY); 
	
// Avoid GDI leaks
dc.SelectObject(hOld);
ReleaseDC(&dc);

Is it impossible to have flicker free drawing during an OnDrawItem operation...??

Keith Rules CMemDC class also doesn't work...???

Am I missing something...???

Thanx in advance.

Cheers Smile | :)

"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr

Tomasz Sowinski29-Jul-02 0:40

29-Jul-02 0:40

I'm not sure if this is related to flicker problem, but you shouldn't call ReleaseDC. Use DeleteDC or just let CDC d'tor do its job.

Tomasz Sowinski -- http://www.shooltz.com

- It's for protection
- Protection from what? Zee Germans?

alex.barylski29-Jul-02 2:09

alex.barylski

29-Jul-02 2:09

Negative... Cry | :((

Nothing that i've learned in the past seems to be effective at stopping flicker...whether its the built in scroll bars or my onwerdrawn code...I hate flicker so very much!!!

Thanx anyways Smile | :)

Cheers

"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr

Tomasz Sowinski29-Jul-02 2:14

29-Jul-02 2:14

You've overriden OnDrawItem or DrawItem? I'm asking because your code draws all over client rectangle. Where's the flicker? On scrollbar or in the window which contains the scrollbar?

Tomasz Sowinski -- http://www.shooltz.com

- It's for protection
- Protection from what? Zee Germans?