faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: Support for exceptions
by El Pseudonymo on Friday 09/Jul/2004, @00:54
|
Hm, but isn't the word "crash" wrong for this situation. I mean, if an exception is not caught, the program terminates in a controlled manner.
Also, the forcing argument has some problems. The first is, it goes either way: If Qt uses exceptions, users are forced to use them. If Qt does not use them, users are forced to use another error reporting scheme. Currently it is not even unproblematic to use exception in you own code if you use Qt, because some users could have compiled Qt without exception support. This will lead to crashes. So Trolltech should at least make a clear statement that Qt 4 should be compiled with exception support.
The second problem with the argument is, that properly used, exceptions do not really force users so much. For example, with the file permissions you described, there return code as error reporting would probably still be used. If exceptions were only used for truly "exceptional" circumstances, users would probably be content with not handling exceptions, and just terminating the program. Of course this depends quite a bit how thouroughly exceptions would really be used. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Support for exceptions
by David on Friday 09/Jul/2004, @10:52
|
1) While "crash" was the incorrect word, I doubt users will much care about the distinction.
2) The "forcing" is a problem. I cannot choose to ignore an exception. I must handle it or my application terminates. But I can ignore an error, even safely in some circumstances.
3) If exceptions were only used for "exceptional" situations, it wouldn't be too bad. But what guarantee will there be of that? This is an area of policy, and without seeing that policy and the mechanisms to enforce it, I simply can't trust it. What's to stop some C++ "purist" at Trolltech from propogating a close() error as an exception?
4) I agree that Qt should be compiled with exception support, even it if doesn't use exceptions itself.
I do not have a problem with using exceptions. I do have a problem with using them in a library, and a lower level library at that, however.
|
[
Reply To This | View ]
|
Re: Support for exceptions
by M on Saturday 10/Jul/2004, @05:54
|
I think not having exceptions in Qt is the major weakness of Qt. All other methods of error handling just lead to massive code bloat.
I assume you mean some sort of Device::close() in your example. You should not ignore an error on close() if that handles a file descriptor for instance, because then there is something seriously wrong with your program.
"Forcing" is not the problem, its us programmers to forget to handle possible errors. Too many people are just too lazy, postpose error handling and forget about it after a while.
And yes, 'crash' is the wrong word, because if there was a QBaseError or something you could just catch that in main() and the program would always terminate with at least an error message, if you forgot to catch the exception at the proper place. Big difference.
|
[
Reply To This | View ]
|
Re: Support for exceptions
by Dawnrider on Saturday 10/Jul/2004, @07:44
|
The trouble with forcing exceptions to be managed is simply that the majority of programmers don't have time to manage every error, or know every error that might be thrown in a given situation. The classic problem, or course, is whether to continue with potentially bad data/state, or to fail. Exceptions ensure the latter in most cases.
Personally, I prefer being able to explicitly handle errors myself knowing what might potentially happen and how critically it will affect my data and running integrity.
The danger of requiring expressions is best expressed by reference to many, many, many pieces of Java code that are running around with:
try
{
<something>
}
catch (Exception e)
{
<do nothing>
}
It turns up much the same arguments as strong vs. loosely/dynamically typed languages.
|
[
Reply To This | View ]
|
Re: Support for exceptions
by El Pseudonymo on Saturday 10/Jul/2004, @10:13
|
I have seen a bit of C++ code, and I have never seen that style, i.e. writing catch-blocks but not doing anything in them. I suspect that almost no C++ programmer would come up with this idea. I have not seen much Java code, but I think there is the difference of checked exceptions, which do not exist in C++ in the way of Java. Such checked exceptions could lead to that style of coding. So, what I am trying to say is basically, this misuse of exceptions will not be seen in C++.
Also, you will not loose any control of handling errors if exceptions are used. Of course, if you really want to deal with *all* exceptions yourself, surround you code with a catch-all handler. A different question is, if that makes sense (Usually not).
I also think that your argument that many programmers do not have the time to manage every error is a very good one in favour of exceptions, since the default behaviour of terminating if nothing is done is the right thing to do then.
|
[
Reply To This | View ]
|
Re: Support for exceptions
by Nicolas Goutte on Saturday 10/Jul/2004, @12:06
|
I am sorry but terminating is not a good solution: the unsaved document... lost! So for me, it is little different than a crash, so perhaps it is not an abrupt crash but a more controlled one.
(Perhaps you will tell me that you can make an emergency save while for a real crash you cannot. But the end-user will not care, for him it is and remains a crash, as the program has terminated abnormaly.)
Have a nice day!
|
[
Reply To This | View ]
|
Re: Support for exceptions
by El Pseudonymo on Saturday 10/Jul/2004, @13:18
|
Yeah, it is not entirely unproblematic. But I really think ignoring errors is worse. Think of an abnormal situation which prevents an application from being able to save a document. Suppose this condition is detected while opening the file which is being worked on. Suppose that is ignored. The user will be happy with editing his important document, and only after he has made his changes, working for some time, out of a sudden, his data will be lost because he can not save. If the application would have terminated right at the start, I think that would have been the better alternative.
Have a nice Saturday night!
|
[
Reply To This | View ]
|
Re: Support for exceptions
by Nicolas Goutte on Saturday 10/Jul/2004, @12:32
|
Well, QIODevice::close has no return value. So we are always ignoring what happens at closing time in KDE...
Have a nice day!
|
[
Reply To This | View ]
|
Re: Support for exceptions
by M on Sunday 11/Jul/2004, @06:42
|
wow, that sucks!
|
[
Reply To This | View ]
|
Re: Support for exceptions
by Allan S. on Sunday 11/Jul/2004, @11:19
|
Why?
The application is closing down. Who gives a fuck?
|
[
Reply To This | View ]
|
Re: Support for exceptions
by Rik Hemsley on Sunday 11/Jul/2004, @16:50
|
The filesystem may not have finished writing the data when close() returns. If it hasn't, you can find out by checking the return value of close(). Many apps really should check the return value of close(), especially when there's a even the slightest chance the file is on an NFS partition.
Rik
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
