But mfc appear to encourage the employ of catch-by-pointer;, C/C++ Programming

Q: But MFC appear to encourage the employ of catch-by-pointer; should I do the similar?

A: Depends. If you're utilizing MFC and catching one of their exceptions, by all means, do it their way. Similar goes for any framework: while in Rome, do as the Romans. Don't attempt to enforce a framework into your way of thinking, even if "your" way of thinking is "better." If you decide to employ a framework, embrace its way of thinking employ the idioms that its authors expected you to use.

But if you're developing your own framework and/or a piece of the system which does not directly based on MFC, then don't catch by pointer only because MFC does it that way. While you're not in Rome, you don't essentially do as the Romans. In this case, you must not. Libraries such as MFC predated the standardization of exception handling in the C++ language, and some libraries employ a backwards-compatible form of exception handling which requires (or at least encourages) you to catch by pointer.

The difficulty with catching by pointer is that it's not clear who (if anyone) is responsible for deleting the pointed-to object. For instance, consider the following:

MyException x;

void f()                                                                                  

{

MyException y;

try {                                                                                                                                              

switch (rand() % 3) {

case 0: throw new MyException;

case 1: throw &x;

case 2: throw &y;

}

}

catch (MyException* p) {

...  should we delete p here or not???!?

}

}

There are three basic problems here:

 

It might be tough to decide whether to delete p in the catch clause. For instance, if object x is inaccessible to the scope of the catch clause, as while it's buried in the private part of some class or is static in some other compilation unit, it may be tough to figure out what to do.

If you solve out the primary problem by constantly using new in the throw (and thus consistently by delete in the catch), then exceptions always employ the heap that can cause problems while the exception was thrown since the system was running low on memory.

If you solve out the first problem by constantly not using new in the throw (and thus consistently not using delete in the catch), then you probably won't be capable to allocate your exception objects as locals (as then they might get destructed too early), wherein case you'll ought to worry about thread-safety, semaphores, locks etc. (intrinsically static objects are not thread-safe).

It isn't to say it's not possible to work through these issues. The point is this: if you catch by reference instead of by pointer, life is easier. Why make life tough when you don't have to?

The moral: ignore throwing pointer expressions, and ignore catching by pointer, unless you're using an existing library that "wants" you to do so.

 

Posted Date: 3/19/2013 8:54:04 AM | Location : United States







Related Discussions:- But mfc appear to encourage the employ of catch-by-pointer;, Assignment Help, Ask Question on But mfc appear to encourage the employ of catch-by-pointer;, Get Answer, Expert's Help, But mfc appear to encourage the employ of catch-by-pointer; Discussions

Write discussion on But mfc appear to encourage the employ of catch-by-pointer;
Your posts are moderated
Related Questions
Structure of C++ Program: Chronological order of C++ program. 1.   Class declaration 2.   Main function program 3.   Member functions definitions 4.   Include heade

how to declare multi dimensional array

Temperature Conversions. Problems 28 through30generate temperature-conversion tables. Use the following equations that give relationships between temperatures in degrees Fahrenheit

Q: In p = new Fred(), does the Fred memory "leak" if  Fred constructor throws an exception? A: No.         If an exception take place during the Fred constructor of p = new F

Greatest Common Divisor (GCD) - The greatest common divisor (GCD) of two integers is the largest integer that will evenly divide both integers. The GCD algorithm involves intege

flowchart of c programing to check the given number is prime or not

padovan string for natural numbers program in java // aakash , suraj , prem sasi kumar kamaraj college program 1 : package test.padovanstring; public class Padov

It tells the compiler that a variable or a function exists, even if the compiler hasn't yet seen it in the file presently being compiled. This variable or function may be distinct

need some help with finishing a program