0

I have seen several c++ projects written by seniors without any exception handling.

ex: I see : className* ptr = new className();

instead of :

 try
 {
     className* ptr = new className();
     //some code/throug exception 
 }
 catch(bad_alloc ba) //or catch some other exception 
 {
     //some code
 }

Usually why people are leaving this try-catch block even if we know that there is chance of exception.

And one more thing, should we use this try/catch format when we are using new ?

When we should go for exception handling exactly(this can be a stupid question, but still I want some ideas as I am confused with exception handling).

Thanks in Advance.

Ankit
  • 1,330
  • 2
  • 11
  • 16
NDestiny
  • 1,133
  • 1
  • 12
  • 28
  • Microsoft seems to recommend exception handling...http://msdn.microsoft.com/en-us/library/4t3saedz.aspx – shree.pat18 Dec 31 '14 at 07:45
  • Probably related: http://stackoverflow.com/questions/7277637/new-stdnothrow-vs-new-within-a-try-catch-block – Mario Dec 31 '14 at 07:47
  • 2
    what are you going to do if you do get a bad_alloc? In 99% of cases all you can do is exit gracefully, which can be handed by a catch in `main()` (or even no catch at all if your compiler puts in a default handler for you). – M.M Dec 31 '14 at 07:48
  • Because such rare exceptions would be handled by the caller, or even by `main` or would terminate the program. The point of exceptions is that they can be handled at upper levels – Basile Starynkevitch Dec 31 '14 at 07:49
  • New suffers from Schizophrenia. Can use exceptions or return nullptr. Anyway there is very little one can do when this is the case except exit gracefully – Ed Heal Dec 31 '14 at 07:49
  • @EdHeal by default `new` cannot return `nullptr`, however of course code can be added to change that (which sucks imho) – M.M Dec 31 '14 at 09:06
  • @MattMcNabb - I think you find that new operator can and does work in both modes. This is a switch with the compiler. (i meant null) – Ed Heal Dec 31 '14 at 09:10
  • @EdHeal: In standard C++ `new` can't return a nullptr, but `new(nothrow)` can and does. A compiler switch that changes that just makes the compiler non-conforming. It's no longer C++. – Cheers and hth. - Alf Dec 31 '14 at 09:52

3 Answers3

3

In C#, Java, Python and many other languages it's generally necessary to use try-catch (or the language's equivalent) in order to be able to clean up properly when an exception occurs. For example, freeing already allocated resources. All three languages mentioned now support a simplified form called using in C#, with in Python, and part of the try (IIRC) in Java, but that's just syntactic sugaring.

In contrast, in C++ object destructors are called automatically when an exception passes through, and they deal with the cleanup chores. This is generally called RAII, which (misleadingly) is short for Resource Acquisition Is Initialization. It's based on deterministic, guaranteed calls of destructors, which you don't have in Java and C#.

So in C++ there's only a need for try-catch where you want to report, retry or suppress. Or, translate an exception to some other exception or failure reporting scheme.

Cheers and hth. - Alf
  • 142,714
  • 15
  • 209
  • 331
1

std::bad_alloc exceptions are ideally handled in main() or in a code fragment which calls a larger routine. Often, you can not handle allocation failures inside small "subfunctions" in a way it is helpful. But for example, if you write something like:

try
{
   ImageProcessor img(resource);
   img.startLargeProcessingRoutine(); // maybe some deeper code functions throw bad_alloc
}
catch(std::bad_alloc &e)
{
   std::cerr << "Not enough memory for processing this resource" << std::endl;
}

you can make good choices about what should happen when a specific operation fails.

cytrinox
  • 1,846
  • 5
  • 25
  • 46
0

IMO it heavily depends on the actual case where you might want to check or ommit something.

Or in other words: If the allocation fails, is there even some way to recover in a graceful way?

You don't have to catch the exception if all you do is showing a popup and closing the program. In fact, Microsoft even doesn't want you to catch exceptions you don't handle gracefully, so they're caught by Windows' own error handling routine (which might also provide you as the dev with minidumps and the like if you have some partnership; never had a closer look at this though, more information can be found here).

I think in the end it boils down to this:

  • If you've got some way to recover, then use the exception block. Use it locally, where it makes sense.

  • If you don't, try to handle your errors at one location. That's also what exceptions are great at. If you'd handle it locally, just show a popup and then kill the program, you wouldn't have to use exceptions to begin with (which might also mean faster code).

Mario
  • 35,726
  • 5
  • 62
  • 78