|
I had a conversation with a friend of mine and he was determined that exceptions were bad if you could get the same effect from returning an error code instead of throwing an exception. Some of the reasons where that exceptions incur way too much overhead, are overly complex and not portable. Are these arguments correct? Also, are there any documents that cover this topic extensively for pros and cons?
Cheers,
Clint
|
|
|
|
|
The problem with checking error codes is that people don't do it. Throwing an exception *forces* your app to deal with them (or die a horrible death).
Exceptions incur overhead, yes, but they should be only used in exceptional cases i.e. for things that should never happen. For example, if you're opening a file you should handle the case where the file is not there. If it's a user opening a Word document, that's a reasonable situation and can be handled by a return code. But if the file *should* be there, that's an exception.
And ask your friend how they are not portable! They are.
Scott Meyers "Effective C++" books are always a good place to start for this kind of thing.
he he he. I like it in the kitchen! - Marc Clifton (on taking the heat when being flamed)
Awasu v0.4a[^]: A free RSS reader with support for Code Project.
|
|
|
|
|
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.
|
|
|
|
|
Tim Smith wrote:
I really doubt that the people who don't check return code care about exceptions.
Ditto.
![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.)
|
|
|
|
|
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).
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
This assumes that all errors result in invalid state. It also assumes that all error codes must be checked.
|
|
|
|
|
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
|
|
|
|
|
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.)
|
|
|
|
|
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
|
|
|
|
|
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.)
|
|
|
|
|
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
|
|
|
|
|
Christian Graus wrote:
Yes, but you must *explicitly* ignore it.
Not really. Human behavior is such that creating a default exception catch using the general handler is becoming second nature. The only way to force this would be to entirely eliminate the concept of a general exception handler.
Christian Graus wrote:
because people are in the habit of ignoring them when they should not.
That same habit has already arrived with exception handling. Only the code is less readable and the possible coding error not at all obvious.
|
|
|
|
|
I am looking for a way to create a sort of "glass" window. A window that is transparent and can be placed on top of other window and can filter mouse clicks using WM_NCHITTEST. It needs to work as a sort of intelligent SetCapture that allows certain click to break the capture.
I tried using WS_EX_TRANSPARENT and can get that to work but it caused the entire desktop to redraw itself. I tried added WS_EX_LAYERED to the window style which the removes the redraw but does not allow me to intercept the mouse clicks 
Using SetCapture does not work since it does not allow for filtering but just blocking messages…
Any suggestions is more than welcome 
Thanks,
Hakon
|
|
|
|
|
|
Thanks, hooks are next on my list of things to try out. However, I seem to remember that adding hooks can slow down the system but my knowledge about hooks might as old as from Charles Petzold's "Programming Windows 3.1"
As far as I can see will the WS_EX_LAYERED let mouse message pass through unless there is painted something on the window or the alpha value is greater than 0 (which means only semi-transparent)....
I will look into hooks 
|
|
|
|
|
I am developing a BlackJack game and cannot find out how to Hide control buttons when the user should not be able to click them. You can set the property in the Properties box of the control ([] Visible) , but I am confused as to how to then make it Visible again when the user has the option to click the button.
Any Help,
Neal
|
|
|
|
|
Use ShowWindow with the SW_SHOW or SW_HIDE flags.
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|
Thanks Alvaro...works like a charm. To think, I was using EnableWindow anyway. At least I know now, Thanks again.
|
|
|
|
|
I am going to start using CVS. I am a one man shop so something big like sourcesafe is not required. My question is, I am using VC.NET and wonder what file I should commit to CVS. I know I should put my header and cpp files, but should I include the .vcproj and .sln files? Can I recreate those files by creating a new project and just adding my header and cpp files into the project, oh and resource directory?
I just notice vcproj, .sln, and other seem to change each time I open VC.NET and I would have revision 1.1 of a file and all of a sudden my .vcproj or .sln file would be revision 50.1 or something.
Thanks for any insight into the matter.
Code4Food
----
"There is no try; only do or do not"
-Yoda
|
|
|
|
|
Commit everything but .aps, .ncb, .suo, and autogenerated header files from idl-files. It's better to create a new module for midl-generated header files IMHO.
.vcproj and .sln you want to keep. it stores information about your project in general (files, compiler settings). Only commit then when you know you've made changes (like added a new file, changed some configuration, etc).
This seems to be working for me so far. 
--
Only in a world this sh*tty could you even try to say these were innocent people and keep a straight face.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
