|
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.
|
|
|
|
|
Thanks for the response!
Code4Food
----
"There is no try; only do or do not"
-Yoda
|
|
|
|
|
I want to know as to how to close my view i.e Kill the view in my MDI Framework when I encounter an error condition .
As for example one of the Initialization routines in the View fails in which case I need to terminate or kill the View. What is the correct way of doing this ? Please help
|
|
|
|
|
DestroyWindow should do it. If not, post some code that may help us assist you.
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|
Hello,
I'm having the following problem; when I try to put a CRectTracker inside a CScrollView, it LOOKS fine, but doesn't actually work. As soon as I scroll an item inside the CRectTracker out of the screen, it appears as if the item IS outside the working area, but the actual rectangle surrounding the item remains stuck to the side on which I scrolled it out. So the picture appears to be half out of the working area, but when I click next to the picture, it still grabs the rectangle and I see the surrounding rectangle line as if the objects border is at the working area border.
Does anyone have a solution for this problem?
Thanks,
- Fahr
|
|
|
|
|
If I understand correctly, you need to use CWnd::SetCapture to capture the mouse event to the view that has the action.
you do a SetCapture on the ButtonDown , and you do a release capture on the ButtonUp.
Max.
|
|
|
|
|
I guess that's not quite what I mean...
Check out the following screenshots, the first one shows where the rectangle is when I select it. The second one is more clear, it shows the border of the rectangle is sizing dots, while the content is obviously scrolled out...
screenshots:
http://www.lycantrope.com:5000/~Vahlinear/recttracker1.jpg
http://www.lycantrope.com:5000/~Vahlinear/recttracker2.jpg
Thanks,
- Fahr
|
|
|
|
|