new returning 0

N

Noah Roberts

Gianni said:
That's probably still a bug in the application code that will bite you
on your first deployment to a paying customer.

Yeah, if it wasn't already out there we would probably try harder. It's
already been on the market for many months though and nothing so...
 
N

Noah Roberts

Gianni said:
While template phobia and not using constructors correctly are valid
criticisms, a healthy dose of reality check of use of exceptions is
something that needs to be evaluated more closely.

Yeah, so you create a reasonable coding policy regarding them. Saying,
"We don't use exceptions," isn't reasonable. Especially when the
reasoning is, "Because they are slow." They are a part of the language
and used HEAVILY by the standard library. It isn't reasonable to just
ignore them.

We now have years worth of code that has absolutely no exception safety
at all.

I agree that they are often misused, but there are also many great
places from which to learn to use them reasonably.

Saving to the original, as in your example, is just poor practice.
Never overwrite the original when your program is in an undefinable
state. I would qualify during a crash as an undefinable state.
 
L

Lionel B

That's probably still a bug in the application code that will bite you
on your first deployment to a paying customer.


Exceptions are kind of special in that I don't often see them used
correctly. Often programmers use it as a return value passing mechanism
rather than "fixing" the interfaces.

Exceptions in C++ could be much better - the nothrow semantics for
example could be compile-time enforced. Debugging with exceptions can
be non-trivial because you loose the context of the exception - this
needs the programmer to log much more information in the case of an
exception.

Exceptions are also used often where and abort should be. A coding
error should be terminal - i.e. stop the process and dump a core file
yet many developers throw an exception hoping to recover only further
exacerbating the problems. Classic case - I use a CAD program, when it
dies, it tries to save the work in progress only to often end up
corrupting the previously saved version.

Agreed totally. My understanding is that exceptions should best (only?)
be used when there is a possibility of recovering from the "exceptional"
condition - where "recovering" might sometimes mean "exit gracefully with
a meaningful error message".

As a case in point, I once had to write dynamic library code that would
be called from a third-party program (a Matlab-alike number cruncher) for
a fairly critical production system. My code could not afford to abort in
the case eg. of being called incorrectly from the third-party system, as
this would bomb out the entire third-party system. Rather, it had to
return an error code and a meaningful error message. By far the easiest
way to achieve this was via exceptions.

For my "personal" code - i.e. code which is not intended for use/
development by others - I frequently turn off exception handling via a
compiler switch which has the basic effect of passing all (eg. STL)
exceptions to a default handler which simply aborts the program (not
particularly gracefully...). The motivation is not so much for efficiency
reasons (although I write scientific code for which speed is frequently
an issue) but rather that I can't afford the time overhead of coding up
meaningful exception handling for code that I am enthusiastically hacking
on ;-)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,768
Messages
2,569,575
Members
45,053
Latest member
billing-software

Latest Threads

Top