C / C++ / MFC

Tim Smith16-Dec-02 13:15

Tim Smith

16-Dec-02 13:15

Exceptions don't require you to handle them. As you said yourself, you just die a nasty death. I really doubt that the people who don't check return code care about exceptions.

Tim Smith

I'm going to patent thought. I have yet to see any prior art.

Nemanja Trifunovic16-Dec-02 17:26

Nemanja Trifunovic

16-Dec-02 17:26

Tim Smith wrote:
I really doubt that the people who don't check return code care about exceptions.

Ditto.

Beer | [beer]

Tim Smith16-Dec-02 13:20

Tim Smith

16-Dec-02 13:20

Exceptions aren't bad. That notion is basically silly. However, I personally don't use them since I don't see much need for them and I wonder if there has been any research that shows they produce more bug free code. Since I do check return code, exceptions just tend to make my code harder to write. But then having to properly handle return codes can also produce icky code.

IMHO, it is personal preference. They are portable. Many implementations are now VERY lightweight. And as someone else stated, yes, throwing an exception does require serious resources, but in general exceptions shouldn't be used for normal program flow. They are, after all, exceptions.

Tim Smith

I'm going to patent thought. I have yet to see any prior art.

Matt Gullett16-Dec-02 17:06

Matt Gullett

16-Dec-02 17:06

I would say that exceptions are an important tool in well written code. Return error codes are good and should be used when it is adequate, but there are serious limitations to return codes. Also, return codes and exceptions are not an all or nothing propisition. Where return codes fall apart is when you need to provide more information about a failure. Yes, there is overhead to exceptions but they are portable. I am working on an article for CP which will cover this topic.

Here's an example that I think basically explains the pros-and-cons of each error method.

I have a function in one of my apps called ScanDirectory which searches a directory for specific file types (they are DLL's), loads them and executes a specific function.

The function prototype looks something like:

short ScanDirectory(LPCTSTR lpszDir)

The ScanDirectory function can return one of the following values which I believe are self explanatory.

0 - All requested files loaded
1 - Directory does not exist
2 - Directory is empty
3 - No files of requested type in directory

This function is required to load ALL dlls succesfully or fail. If this function attempts to load a DLL and fails, I throw an exception. I do this because I want to report back to the calling function what DLL failed to load, the reason it failed to load and any other infomration I have on the error.

Just my 2 cents.

Alvaro Mendez16-Dec-02 17:09

Alvaro Mendez

16-Dec-02 17:09

Exceptions are a great way to write clean and maintainable code. Their benefits far outweigh any extra-overhead concerns you may have. You can just read lines of code without being distracted by the all the possible error conditions that can come from every method call. Then if you're really interested in seeing how errors are handled, you go to one or two places in the code that catch the exceptions, instead of all over the place.

A great argument for using exceptions that comes to mind is the new languages such as Java and the .NET ones. They all make extensive use of exceptions in their libraries. It's interesting to note that in C++, exceptions have more overhead because the compiler has to deal with calling destructors for all the locally defined objects, in addition to unwinding the stack. Still, it's probably not a lot less innefficient than the code the compiler executes when a regular block is closed.

Of course, it should be noted how to properly use exceptions. They should be thrown only in the case of errors that cause the flow of the code to be interrupted, and should be caught only in places that can properly deal with them.

Regards,
Alvaro

Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)

Nemanja Trifunovic16-Dec-02 17:30

Nemanja Trifunovic

16-Dec-02 17:30

I have mixed feelings about exceptions. We use them all the time in the company I work for, and I've had a chance to see both good and bad sides of them.

The best thing about them, IMHO, is that it is possible to make exception classes that enable logging. Whenever an exception is thrown, it is written in a log file (the kind of exception, the user-supplied message, time, and even the source file name and line number).

Beer | [beer]

nde_plume16-Dec-02 17:33

nde_plume

16-Dec-02 17:33

Exeptions, like anything are bad if you misuse them.
Exceptions are designed for major errors that essentially
stop processing at a macro level. To put it in rather
over precise terms, exceptions should be used for the
sorts of errors you are going to report to you users,
(usually acompanied by "Save your data, this system
is in trouble.") Since it is generally a user interaction,
performance per se is not very relevant (becuase people
operate much slower than computers.)

Exceptions are important for writing good quality code
for several reasons:

1. They allow a much cleaner separation of very unlikely
error handling from the main flow of code, meaning
that your code is generally clearer. As a trivial
but important example of that, exceptions mean you
don't need to check the return code of new for NULL
(our of memory.)

2. As a corollory of the above, code is rather eaiser to
write, because you are not constantly distracted by
what to do if your run out of memory, the network goes
down, the database locks where it shouldn't etc.

3. Also as a corollory, error checking is much more
consistently done in code. How many times have you
forgotten to check the return code of malloc? Huh?
You know that that one rare occasion when you run out
of memory will be in the one out of a hundred mallocs
you forgot to check.

4. Exceptions make it feasible to send data with your
error code, something which is either hard or a hack
to do with return codes. By data I mean significant
data, rather than just an integer indication of the
error type. For example, you can throw an exception
indicating which database record you couldn't lock,
or where the network accidentally terminated during
your ftp session.

5. Using the mechanisms for rethrowing exceptions, the
above can be made even more powerful by decorating
the exception as the stack unwinds. (For example,
you catch a network error in your network code, and
rethrow the exception with the IP address attached.
This is caught in your FTP code, which adds information
to the exception that it was an FTP session, and what
file, which is again rethrown, then your web design
tool catches that again, and reports a detailed error
message to the user. Such collection of data from
disparate locations on the stack would be very hard
to do otherwise.)

6. Exceptions allow you to jump way out of context to the
best place to handle the exception (somewhere down
the call stack), but do so in such a way as to largely
prevent leaking of resources, and nautral clean up by
calling destructors on the way down. (Note this doesn't
work perfectly, unless you manage to stay away from
raw new and delete -- which is generally possible with
smart pointers and the STL.)

7. Exceptions are a necessary part of implementing clean
Object oriented designs. Why? Because if you find an
error in your constructor, you cannot return an error
code (because constructors don't return values.) You
need to throw an exception. The only other approach is
to use an error flag in the object, which leaks your
abstraction, making for more complex programs.

Anyways there are seven reasons off the top of my head.

BTW, one poster suggested that exception handling was
fat because it required unwinding the stack and calling
the destructors. That isn't true. Exception handling is
inherently wasteful of time and memory simply because
it is the necessary trade off so that exception handling
causes zero cost on code that doesn't use them.

Christian Graus16-Dec-02 20:49

16-Dec-02 20:49

Microsoft are moving from an error code format to exceptions. Reasons include the simple fact that most programmers do not check return codes and so go on their merry way with invalid state.

Christian

No offense, but I don't really want to encourage the creation of another VB developer.
- Larry Antram 22 Oct 2002

C# will attract all comers, where VB is for IT Journalists and managers - Michael
P Butler 05-12-2002

Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not
as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002

Joe Woodbury17-Dec-02 12:17

17-Dec-02 12:17

This assumes that all errors result in invalid state. It also assumes that all error codes must be checked.

Christian Graus17-Dec-02 12:29

17-Dec-02 12:29

Joe Woodbury wrote:
This assumes that all errors result in invalid state.

OK - potentially invalid state then.

Joe Woodbury wrote:
It also assumes that all error codes must be checked.

Not a bad assumption to make, now is it ?

Christian

No offense, but I don't really want to encourage the creation of another VB developer.
- Larry Antram 22 Oct 2002

C# will attract all comers, where VB is for IT Journalists and managers - Michael
P Butler 05-12-2002

Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not
as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002

Joe Woodbury17-Dec-02 12:46

17-Dec-02 12:46

Christian Graus wrote:
Not a bad assumption to make, now is it ?

Actually, yes. Many existing APIs don't distinguish between critical, major or minor error codes. In many cases, it turns out that the API will never return a critical error code.

(I've written functions which return error codes that should only be checked during testing since the function is designed to fail in a designed way internally.)

Christian Graus17-Dec-02 12:59

17-Dec-02 12:59

Joe Woodbury wrote:
Many existing APIs don't distinguish between critical, major or minor error codes. In many cases, it turns out that the API will never return a critical error code.

In that case, it's a good thing that Microsoft is moving to a more stable/logical design, isn't it ?

Joe Woodbury wrote:
(I've written functions which return error codes that should only be checked during testing since the function is designed to fail in a designed way internally.)

Naturally, when you own the code, you can choose to employ whatever mechanism that seems right to you. But it has been a problem under windows that many API's do return meaningful error information, which is never stored or referred to.

Christian

No offense, but I don't really want to encourage the creation of another VB developer.
- Larry Antram 22 Oct 2002

C# will attract all comers, where VB is for IT Journalists and managers - Michael
P Butler 05-12-2002

Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not
as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002

Joe Woodbury17-Dec-02 16:45

17-Dec-02 16:45

Christian Graus wrote:
In that case, it's a good thing that Microsoft is moving to a more stable/logical design, isn't it ?

But they aren't. Simply because .NET has a more consistant error model doesn't mean the OS is. Moreover, I don't see that as making anything intrinsically more stable. Not that it matters, we have what we have.

Christian Graus wrote:
But it has been a problem under windows that many API's do return meaningful error information, which is never stored or referred to.

I seriously fail to see your point. As I said, for many API's the error information may be interesting, but may still be safely ignored. (Even in .NET you can catch an exception then ignore doing anything about it.)

Christian Graus18-Dec-02 18:00

18-Dec-02 18:00

Joe Woodbury wrote:
(Even in .NET you can catch an exception then ignore doing anything about it.)

Yes, but you must *explicitly* ignore it.

Joe Woodbury wrote:
As I said, for many API's the error information may be interesting, but may still be safely ignored.

Which is a real problem, because people are in the habit of ignoring them when they should not.

Christian

No offense, but I don't really want to encourage the creation of another VB developer.
- Larry Antram 22 Oct 2002

C# will attract all comers, where VB is for IT Journalists and managers - Michael
P Butler 05-12-2002

Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not
as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002

Joe Woodbury19-Dec-02 5:17