Re: new(nothrow not even from constructor)
In article <10f8af47-44b5-49df-a4f9-a01e71456269@g25g2000yqn.googlegroups.com>,
Goran <goran.pusic@gmail.com> wrote:
On Dec 20, 2:12?pm, Virchanza <virt...@lavabit.com> wrote:
I've been using null pointers for so long, I just prefer them. Plus I
find the "try catch" notation to be a bit long-winded.
If find the following awfully long winded and confusing:
type retVal = tryToDoSomething()
if ( retVal != someExpectedValue )
{
// do the error handling code
// more error handling code
}
retVal = tryToDoSomethingElse()
if ( retVal != someExpectedValue )
{
// do the error handling code
// more error handling code
}
retVal = tryToDoAnotherThing()
if ( retVal != someExpectedValue )
{
// do the error handling code
// more error handling code
}
Compared with:
try
{
tryTodoSomething();
tryToDoSomethingElse();
tryToDoAnotherThing();
}
catch(...)
{
// do the error handling code
// more error handling code
}
try/catch is longer than an "if", but if your code has a lot of try/
catch-ing, you're doing it wrong. As opposed to ifs of error-return,
you should have about an order of magnitude less try/catch-es with
exceptions. Indeed, your attempt to catch failure in object creation
the way you have shown, is IMO wrong.
Exactly, the point is that you should not enclose single statement in
a try-catch block by simply replacing you line by line if/else error
handling by a try block. You should have a normal success path where
the logic progresses unless an exception is thrown and a catch that
handle the error path.
There's no modern C++ without exceptions (at least, there's very
little of it). Everything throws. new throws, string1+string2 throws,
push_back throws (because new throws, and you can't use non-throwing
new because of that)...
I seriously suggest that you change your preference, because if you
don't, you will constantly fight an uphill battle while working.
You are probably living in the worse of both worlds where you either
have to handle both the return code as error code and the possibility
of exceptions duplicating the require effort needed to handle errors.
Alternatively, you might be simply writing exception unsafe code.
Yannick