The extreme set of rules that you listed are rules that the USA already has in place via the US's largest private ISPs,
What? I used to run my own webserver out of my room at my mom's house, using a typical residential ISP, when I was in high school and for most of college. None of the rules I listed are a reality in the US; I am free to criticize the Thai leadership and send that criticism to Thai citizens, I am free to post anonymous messages, I pay no extra fee for access websites across international borders, and so forth.
I am not in the know, but do the rules governing the internet respect International Law?
When did international law start governing communication between people? That's all the Internet is: a really good way for people to communicate (which has a lot of good side effects).
A switch over will be a few wiring changes, and the data will now be available in the new globally owned internet. Most end-users will not notice any difference.
The Internet is not "globally owned" if it is run by the UN; the UN is only a democracy between governments, and many of the powerful voices in the UN do not come from democracies. An Internet that China has a say over is an Internet that is not "globally owned" by any stretch of the imagination.
No, I think that any system with an IP address should be able to act as a server for whatever protocol the operator wants. My point was that the ITU would almost certainly change that, so that different systems have different service classes.
Having a VPS will not really help; if you are providing a service, you will need to follow the rules for your service class. Do you think your rented VPS will somehow escape rules that require you to refuse service to people whose governments' object to that communication? Do you think your VPS host will even allow you to provide service to other countries?
What makes you think proxy servers, Tor, etc. will still be possible after the ITU starts make "recommendations" (i.e. rules) for the Internet? In the Y series recommendations, you can find suggestions for "non-repudiation" in "next generation networks" -- i.e. that users should not be able to disassociate their names from their online activities.
Really, when ICE hijacks a DNS entry, they are not stepping outside of US borders; you can register your DNS name as a.co.uk or whatever for your country, and the US will not legally touch you (or your government will cooperate, but at least that is your government and not some hack).
What we really need is a decentralized system of Internet governance, but transferring to the UN is basically a step in the opposite direction.
US -- ICE hijacks DNS entries and can be circumvented with a browser extension.
Countries pushing for UN control -- national firewalls, a constant cat-and-mouse game to circumvent those firewalls, requirements that ISPs participate in censorship, censorship of political opinions, censorship of news (facts), criminalization of the act of circumvention in addition to distributing circumvention tools, etc.
Now, I am not one to defend ICE or any of the US government's Internet censorship, but let's be clear: the difference between what China, Russia, and others are doing and what the US does is the difference between night and day.
Say someone in the US makes jokes about the Thai rulers. Their website can be dropped off the net
You seem to think that ITU would continue the policy of "anything with an IP address can be a service provider (e.g. a web server)" -- I think ITU would divide Internet hosts into three or more classes: government, commercial service provider, and consumer. Government systems would have special privileges / no restrictions, but would have to serve a function of government (perhaps this could include propaganda). Commercial service providers would be things like Facebook, Youtube, etc. -- potentially run by the government, but not classified as government systems. Service providers would be required to obey the laws of any country whose citizens they provide service to so e.g. if you make fun of the Thai leader, you must not serve pages to Thai citizens. Consumers would not be able to operate servers at all, except as needed to participate in some system (e.g. a video game might need to listen on a particular port, but it would be illegal to run a web server or IRC server that listens on such a port).
So rather than a website that jokes about Thai monarchy being knocked off the net, the website would be required to refuse service to Thai citizens. Thus China would not need to block the NY Times with its Great Firewall; the NY Times would be required to refuse service to Chinese citizens.
What do you think ITU cares about more: national sovereignty, or promoting some hacker ideal about free communication?
Well, take a look at some of the ITU-T Y series recommendations if you want to know where these ideas come from. A lot of it is technical e.g. protocols and ways to interoperate, but some of it is related to policy -- like requirements for non-repudiation in "next generation networks."
In general, the UN respects national sovereignty i.e. the UN will not authorize intervention in a country's laws or government unless the violations of human rights are extreme (and even then, they show their bias -- like sending peacekeepers to central Africa and ordering them to not discharge any firearms). This is mainly because countries like China and Russia would never have bothered with the UN if they would have been required to change their laws. The UN was originally created to prevent another world war, not to spread freedom or democracy.
Unfortunately, this means that the UN is not going to do anything that threatens the Great Firewall or similar national firewalls if they gain control of ICANN or otherwise have a say in Internet policy and governance. More likely, the UN would listen to the complaints of China -- those horrible Americans with their NY Times and Google -- and work to create a system that forces countries to respect each other's Internet laws (including censorship). That is how we keep the peace.
See, I disagree on this; my view is that control should be decentralized. The fact that giving the UN control would worsen the situation does not mean that ICANN should remain in charge. We need to lower the barriers to entry when it comes to peering, develop a better system for domain names, and get IPv6 deployed -- then we can say that anyone with networking equipment and a minimum level of technical knowledge can participate in running and governing the Internet.
Don't accept the lesser of two evils, promote a better solution
Here is something that would go a long way: reduce the barriers to entry for peering with ISPs. The requirements many ISPs have for peering make it impossible for a small, community-run network to become part of the Internet; such networks generally wind up paying for service from a telecom monopoly.
A global network can be governed by its users (or at least those who have the equipment and expertise needed to participate); Fidonet comes to mind here.
Indeed, but there is no strong push for handing control of the Internet over to its users. The choice we have right now is this:
ICANN, under US jurisdiction (but autonomous within the boundaries of US law).
ITU, which has a goal of satisfying the regulatory and policy demands of all countries simultaneously, and which is part of the UN, which consistently seeks to respect "national sovereignty."
So don't get me wrong -- I would love if the Internet were truly a "network of networks" and if peering was not reserved for large telecom monopolies. ITU control will get us further away from that goal, at least if their approaches to other global communications systems and the Y series recommendations are any indication.
If I were other countries, I'd ask myself why any one country should be "in charge" of things like DNS.
No one country is in charge of DNS; some important domain names fall under the jurisdiction of the US government, but country-specific TLDs belong to specific countries. IP allocations are a different story, but ICANN is not controlled by the US government, it is just under the US government's jurisdiction.
I know full well that there are countries that do not like the job ICANN is doing. Countries that have national firewalls -- not the weak attempt by ICE (DNS hijacking), but real firewalls that actually inspect packets and kill connections -- want to change the rules to make censorship easier. China would prefer if other countries would just require servers to refuse to give "objectionable" information to Chinese citizens. The reason those sorts of countries are turning to the UN is that unlike the US, the UN actually respects those censorship campaigns (after all, national sovereignty must be respected, even if it violates the UN's definition of human rights) and will try to force everyone else to respect those campaigns.
UN control of the Internet would kill the Internet as we know it. Long distance fees, requirements that you respect censorship laws in other countries, unique identification requirements, different regulatory classes for "service providers" and "consumers" are all on the table for the UN. Sure, they would do a great job of ensuring that everyone is happy -- everyone being defined as the governments that are represented in the UN, which include several powerful governments with strong and pervasive censorship campaigns.
what about people who do what they do for fun rather than profit, like popular bloggers?
Maybe they should not be trying to get their message out on Facebook. We still have an Internet that allows people to run their own system; it is not as though people have to go through Facebook to get to the websites they are trying to view.
Facebook is a big corporation now, and they need to make money -- which means catering to other big corporations. At least they are becoming honest about why they exist (advertising) instead of continuing to pretend that they are on a mission to connect people to their friends. Popular blogs should look into being paid for advertising impressions rather than clicks as well -- it is a much better model.
Yeah but promoted posts are (as far as I can tell) a non-click-through sort of advertising. Much as I criticize Facebook, this sort of thing is a good thing for the web: monetizing by advertisement impressions rather than by clicks is how we should have been doing things in the first place. This is just a fancy form of impressions -- you are pushing your post to the top of a person's view, so that it comes before the posts from their friends etc.
It is not unenforceable, and it is not "stupid" -- handguns are common targets for thieves, and those guns are used by criminals. That is a real problem, and one of the ways to mitigate that problem is to store your guns in a safe. Enforcement is not a matter of going door to door and performing checks; it is a matter of what happens if the gun is stolen or used without permission.
OK, and I did not say it is impossible to do that -- just that it is needlessly difficult, and that as a result it is unusual. People have also written high quality software in assembly language, but if you needed to write high quality software, I doubt that assembly language would be your first choice.
Client code that will ignore my error code is client code that won't catch my exception
Except that the behavior of a program following an unhandled error is essentially undefined -- the only well-defined behavior is to terminate. That's what exceptions give you; if the programmer does not define how an error should be handled, the program just stops. In terms of a state machine model, if the program enters an error state and has no transitions out of that state, it halts.
The difference is that not all of my errors are fatal, whereas by definition every exception is.
No, not all exceptions are fatal, at least not in languages that support restarts or continuations. You can have exceptions that are recoverable or ignorable; the programmer just needs to specify that that is what should happen.
Example, parsing a numeric string. If I cannot convert the string to an integer, I could set the value to 0 and return/set an error code. If the error code is ignored, the program will not crash.
Unless you try to divide by the integer you converted to, in which case you crash, and you lose the information about why you crashed. This can be even worse: you might have been trying to read the price of an item, but a thumb drive was removed, and now the price is set to zero -- which is not what you wanted. Unhandled errors are bad things and should be discouraged.
we're talking real life here, not the idealized world they taught us in college
In real life, unhandled errors cause worse problems than program crashes:
The solution is to, as best as is possible, deal with the error at the point that it occurs, instead of handing it off to someone else with less knowledge to deal with.
Sure, but sometimes you really have no other choice. If the disk is full, you can possibly correct the error by asking the user to remove some files; but if you are not interactive, then you cannot do so. Exceptions with restarts are the answer; not error codes, and certainly not allowing client code to just ignore error states.
I don't understand this - of course you have to prevent some exceptions from propagating - ie catching them.
That is not what I mean; what I mean are things like destructor exceptions e.g. closing a file can result in an error condition, and exceptions are basically the only reliable mechanism to signal that. In C++, iostream classes have that exact issue, and the standard dictates precisely what I said: if closing a file causes an exception to be raised, the destructor must catch it and do nothing, which is another way to say that the error will happen silently. There was, I am told, a very lengthy debate about this on Usenet and in committee meetings, because some people wanted a Lisp-style restarts system (or no change from C++98), but the committee went a different way on this issue.
Similarly, you could say you should never return an error code if you're not prepared to check it
There are two non-cosmetic differences:
There is no way to guarantee that a C++ program will check an error code, nor does the language actually require such a thing. The best we have are separate tools that allow us to assert and prove that error codes are being checked, which can be used by programmers who want to do such things. With exceptions you are at least guaranteed a runtime error if the exception is not handled.
There are some situations where an error code would not even be feasible. When a function is called, objects are copied; the copy constructor may have an error, but there is no sequence point between the copy constructor calls. You would need a very complex system for registering the error codes, and in C++ this is even worse because the order of copy constructor calls is undefined. This is the real selling point of exceptions: you can signal an error even in places where functions are not explicitly called.
Really, in a language like C++, exceptions are the only good way to signal errors; that is why getting exceptions right is critical to enabling programmers to write reliable code, and why getting exceptions wrong (which I contend is what happened in C++11) makes writing reliable code far more difficult.
So how to make exceptions opt-out rather than opt-in... the only way is to inspect all the exceptions a piece of code will throw (and the code it uses itself) and then create handlers for each of them, or just wrap all function calls with a generic catch(...) handler which will at least provide a quick and easy way to catch all those exceptions, unless you handle them first. So the best practice is really to write the equivalent of a switch's 'default' case every time.
Yes, and there is a top level catch-all that will terminate the program in any language that has exceptions. That is a fine thing to do, but consider the difference in Common Lisp (at least those implementations I have used): the top level catch-all presents the user with options that are specified by the function which throws the exception. Thus a failed attempt to close a file might give the user a "try again" option, which the user can use after freeing disk space. Clearly such a thing will not always work: the program might be non-interactive, but you can always override this behavior with your own top level catch-all.
As a final thought, the C++ goal of being both high- and low-level has questionable merit. High level programming is only about program logic; low level programming involves some logic, but must also deal with mechanics. Most of the code that is in use today is high level i.e. there is nothing machine-specific about it, it was written to implement a particular abstract algorithm or process. This is true of C++ code as well: most C++ code is high level code. Unfortunately, in order to satisfy the needs of low level programmers, C++ does not provide certain high level features (garbage collection being the most prominent, but also multiple dispatch
And my experience has taught me that you never through an exception you yourself aren't prepared to catch.
That's fine if you have a good way to signal errors to client code. Error codes and return values are lacking in that department, because client code can (and probably will) ignore them.
You seem to be wrongfully blaming deficiencies in Qt's implementation on the langauge
I was originally replying to a post that claimed Qt was the "best" toolkit for writing "high quality" C++ programs. Qt uses error codes, not because error codes are a good thing (they are not), but because Qt is a C++ toolkit and C++ makes anything other than error codes unreliable. How is that an unfair criticism?
I've written numerous pieces of complex software with Qt using exceptions and have never seen an exception fail to be caught or ever let errors go unchecked
Except that preventing exceptions from crashing your program in C++ means preventing some exceptions from propagating -- and basically forces you to create programs that do not handle certain errors. In C++98, you could just risk a double exception fault, but it was considered bad practice; in C++11, you can't even take that risk, and so your destructors either have to handle the error properly or you need to find some other way to signal the error (or else let it go unhandled or just quit). On some level, you are either not using exceptions at all or else you are allowing some exceptions to be ignored -- that's a reality of C++ exception handling.
I've used tons of crappy Java and.Net
Did I say that Java or.NET are better? In all of these systems, exceptions could have been done better -- for example, by not destroying the stack before the exception handler executes. Java won't cause your program to abort when exceptions are thrown, but Java will cause exceptions to be "forgotten" under some circumstances:
try { } finally { throw new SomeException(); }
That is not much better if you want "high quality" software.
You might want to update your C++ hater points beyond what you read on yosefk.com or other lame whiner sites.
Lame whiner sites? I programmed C++ for a decade, and I still have to write C++ code sometimes. My dislike of the languages comes from experience, not from some website. Error handling is just one issue, one that I think is very much relevant if we are going to talk about "high quality" software. Programming in C++ requires knowledge of the long list of undefined behavior, the long list of patterns that have to be used to avoid that behavior (which hardly anyone deviates from, except for novices who have not yet learned the patterns), and debugging is as much about correcting bad program mechanics as it is about correcting bad program logic (and the majority of C++ code is not low level code).
Yes, I know, programmers should just follow best practices; if that is the case, why not just make those practices standard, and create a special statement to disable that behavior? Why are we forcing programmers to explicitly say, "I do not want this program to crash," when we could be forcing them to be explicit in situations where they do want to write potentially unsafe code?
The problem is that "high quality software" should handle errors -- it should not crash when an error occurs (in the worst case, it should gracefully shut down), and it should not ignore errors. Error codes are fine as long as you actually handle them, but in practice the effort required to check the return value of every function call (and you think checked exceptions are annoying?) leads to some errors not being detected or handled. That is why exceptions are good in theory; but if in practice, an exception can cause a program crash even when there is an exception handler waiting to catch the exception (this is the case in C++), then they are not a good way to deal with errors.
As for embedded systems, if there is enough computational power to display a GUI, I really do not see how exceptions are problematic.
Not really; look at the state of exception handling in C++ and get back to me about "high quality" software. In fact, Qt's own documentation says this:
Exception safety is not feature complete! Common cases should work, but classes might still leak or even crash.
And,
Qt itself will not throw exceptions. Instead, error codes are used.
Did I say anything about inspections? You do realize that making something illegal, and going around inspecting people's homes for violations, are two very different things right?
Slashdot Mirror
if you're going to peer, you need to make sure you can be trusted to not fuck up everyone elses' interconnects
I see no reason to assume that a large ISP would not screw things up. In fact, I recall this counterexample:
http://www.technewsworld.com/rsstory/71258.html
The extreme set of rules that you listed are rules that the USA already has in place via the US's largest private ISPs,
What? I used to run my own webserver out of my room at my mom's house, using a typical residential ISP, when I was in high school and for most of college. None of the rules I listed are a reality in the US; I am free to criticize the Thai leadership and send that criticism to Thai citizens, I am free to post anonymous messages, I pay no extra fee for access websites across international borders, and so forth.
I am not in the know, but do the rules governing the internet respect International Law?
When did international law start governing communication between people? That's all the Internet is: a really good way for people to communicate (which has a lot of good side effects).
A switch over will be a few wiring changes, and the data will now be available in the new globally owned internet. Most end-users will not notice any difference.
The Internet is not "globally owned" if it is run by the UN; the UN is only a democracy between governments, and many of the powerful voices in the UN do not come from democracies. An Internet that China has a say over is an Internet that is not "globally owned" by any stretch of the imagination.
No, I think that any system with an IP address should be able to act as a server for whatever protocol the operator wants. My point was that the ITU would almost certainly change that, so that different systems have different service classes.
Having a VPS will not really help; if you are providing a service, you will need to follow the rules for your service class. Do you think your rented VPS will somehow escape rules that require you to refuse service to people whose governments' object to that communication? Do you think your VPS host will even allow you to provide service to other countries?
What makes you think proxy servers, Tor, etc. will still be possible after the ITU starts make "recommendations" (i.e. rules) for the Internet? In the Y series recommendations, you can find suggestions for "non-repudiation" in "next generation networks" -- i.e. that users should not be able to disassociate their names from their online activities.
What China does only affects their own citizens?
.co.uk or whatever for your country, and the US will not legally touch you (or your government will cooperate, but at least that is your government and not some hack).
http://www.huffingtonpost.ca/2011/06/02/gmail-hacked-from-china-google_n_870126.html
Really, when ICE hijacks a DNS entry, they are not stepping outside of US borders; you can register your DNS name as a
What we really need is a decentralized system of Internet governance, but transferring to the UN is basically a step in the opposite direction.
Now, I am not one to defend ICE or any of the US government's Internet censorship, but let's be clear: the difference between what China, Russia, and others are doing and what the US does is the difference between night and day.
Say someone in the US makes jokes about the Thai rulers. Their website can be dropped off the net
You seem to think that ITU would continue the policy of "anything with an IP address can be a service provider (e.g. a web server)" -- I think ITU would divide Internet hosts into three or more classes: government, commercial service provider, and consumer. Government systems would have special privileges / no restrictions, but would have to serve a function of government (perhaps this could include propaganda). Commercial service providers would be things like Facebook, Youtube, etc. -- potentially run by the government, but not classified as government systems. Service providers would be required to obey the laws of any country whose citizens they provide service to so e.g. if you make fun of the Thai leader, you must not serve pages to Thai citizens. Consumers would not be able to operate servers at all, except as needed to participate in some system (e.g. a video game might need to listen on a particular port, but it would be illegal to run a web server or IRC server that listens on such a port).
So rather than a website that jokes about Thai monarchy being knocked off the net, the website would be required to refuse service to Thai citizens. Thus China would not need to block the NY Times with its Great Firewall; the NY Times would be required to refuse service to Chinese citizens.
What do you think ITU cares about more: national sovereignty, or promoting some hacker ideal about free communication?
Well, take a look at some of the ITU-T Y series recommendations if you want to know where these ideas come from. A lot of it is technical e.g. protocols and ways to interoperate, but some of it is related to policy -- like requirements for non-repudiation in "next generation networks."
In general, the UN respects national sovereignty i.e. the UN will not authorize intervention in a country's laws or government unless the violations of human rights are extreme (and even then, they show their bias -- like sending peacekeepers to central Africa and ordering them to not discharge any firearms). This is mainly because countries like China and Russia would never have bothered with the UN if they would have been required to change their laws. The UN was originally created to prevent another world war, not to spread freedom or democracy.
Unfortunately, this means that the UN is not going to do anything that threatens the Great Firewall or similar national firewalls if they gain control of ICANN or otherwise have a say in Internet policy and governance. More likely, the UN would listen to the complaints of China -- those horrible Americans with their NY Times and Google -- and work to create a system that forces countries to respect each other's Internet laws (including censorship). That is how we keep the peace.
See, I disagree on this; my view is that control should be decentralized. The fact that giving the UN control would worsen the situation does not mean that ICANN should remain in charge. We need to lower the barriers to entry when it comes to peering, develop a better system for domain names, and get IPv6 deployed -- then we can say that anyone with networking equipment and a minimum level of technical knowledge can participate in running and governing the Internet.
Don't accept the lesser of two evils, promote a better solution
Here is something that would go a long way: reduce the barriers to entry for peering with ISPs. The requirements many ISPs have for peering make it impossible for a small, community-run network to become part of the Internet; such networks generally wind up paying for service from a telecom monopoly.
A global network can be governed by its users (or at least those who have the equipment and expertise needed to participate); Fidonet comes to mind here.
So don't get me wrong -- I would love if the Internet were truly a "network of networks" and if peering was not reserved for large telecom monopolies. ITU control will get us further away from that goal, at least if their approaches to other global communications systems and the Y series recommendations are any indication.
If I were other countries, I'd ask myself why any one country should be "in charge" of things like DNS.
No one country is in charge of DNS; some important domain names fall under the jurisdiction of the US government, but country-specific TLDs belong to specific countries. IP allocations are a different story, but ICANN is not controlled by the US government, it is just under the US government's jurisdiction.
I know full well that there are countries that do not like the job ICANN is doing. Countries that have national firewalls -- not the weak attempt by ICE (DNS hijacking), but real firewalls that actually inspect packets and kill connections -- want to change the rules to make censorship easier. China would prefer if other countries would just require servers to refuse to give "objectionable" information to Chinese citizens. The reason those sorts of countries are turning to the UN is that unlike the US, the UN actually respects those censorship campaigns (after all, national sovereignty must be respected, even if it violates the UN's definition of human rights) and will try to force everyone else to respect those campaigns.
UN control of the Internet would kill the Internet as we know it. Long distance fees, requirements that you respect censorship laws in other countries, unique identification requirements, different regulatory classes for "service providers" and "consumers" are all on the table for the UN. Sure, they would do a great job of ensuring that everyone is happy -- everyone being defined as the governments that are represented in the UN, which include several powerful governments with strong and pervasive censorship campaigns.
what about people who do what they do for fun rather than profit, like popular bloggers?
Maybe they should not be trying to get their message out on Facebook. We still have an Internet that allows people to run their own system; it is not as though people have to go through Facebook to get to the websites they are trying to view.
Facebook is a big corporation now, and they need to make money -- which means catering to other big corporations. At least they are becoming honest about why they exist (advertising) instead of continuing to pretend that they are on a mission to connect people to their friends. Popular blogs should look into being paid for advertising impressions rather than clicks as well -- it is a much better model.
Yeah but promoted posts are (as far as I can tell) a non-click-through sort of advertising. Much as I criticize Facebook, this sort of thing is a good thing for the web: monetizing by advertisement impressions rather than by clicks is how we should have been doing things in the first place. This is just a fancy form of impressions -- you are pushing your post to the top of a person's view, so that it comes before the posts from their friends etc.
It is not unenforceable, and it is not "stupid" -- handguns are common targets for thieves, and those guns are used by criminals. That is a real problem, and one of the ways to mitigate that problem is to store your guns in a safe. Enforcement is not a matter of going door to door and performing checks; it is a matter of what happens if the gun is stolen or used without permission.
OK, and I did not say it is impossible to do that -- just that it is needlessly difficult, and that as a result it is unusual. People have also written high quality software in assembly language, but if you needed to write high quality software, I doubt that assembly language would be your first choice.
Client code that will ignore my error code is client code that won't catch my exception
Except that the behavior of a program following an unhandled error is essentially undefined -- the only well-defined behavior is to terminate. That's what exceptions give you; if the programmer does not define how an error should be handled, the program just stops. In terms of a state machine model, if the program enters an error state and has no transitions out of that state, it halts.
The difference is that not all of my errors are fatal, whereas by definition every exception is.
No, not all exceptions are fatal, at least not in languages that support restarts or continuations. You can have exceptions that are recoverable or ignorable; the programmer just needs to specify that that is what should happen.
Example, parsing a numeric string. If I cannot convert the string to an integer, I could set the value to 0 and return/set an error code. If the error code is ignored, the program will not crash.
Unless you try to divide by the integer you converted to, in which case you crash, and you lose the information about why you crashed. This can be even worse: you might have been trying to read the price of an item, but a thumb drive was removed, and now the price is set to zero -- which is not what you wanted. Unhandled errors are bad things and should be discouraged.
we're talking real life here, not the idealized world they taught us in college
In real life, unhandled errors cause worse problems than program crashes:
http://descriptions.securescout.com/tc/16657
The solution is to, as best as is possible, deal with the error at the point that it occurs, instead of handing it off to someone else with less knowledge to deal with.
Sure, but sometimes you really have no other choice. If the disk is full, you can possibly correct the error by asking the user to remove some files; but if you are not interactive, then you cannot do so. Exceptions with restarts are the answer; not error codes, and certainly not allowing client code to just ignore error states.
I don't understand this - of course you have to prevent some exceptions from propagating - ie catching them.
That is not what I mean; what I mean are things like destructor exceptions e.g. closing a file can result in an error condition, and exceptions are basically the only reliable mechanism to signal that. In C++, iostream classes have that exact issue, and the standard dictates precisely what I said: if closing a file causes an exception to be raised, the destructor must catch it and do nothing, which is another way to say that the error will happen silently. There was, I am told, a very lengthy debate about this on Usenet and in committee meetings, because some people wanted a Lisp-style restarts system (or no change from C++98), but the committee went a different way on this issue.
Similarly, you could say you should never return an error code if you're not prepared to check it
There are two non-cosmetic differences:
Really, in a language like C++, exceptions are the only good way to signal errors; that is why getting exceptions right is critical to enabling programmers to write reliable code, and why getting exceptions wrong (which I contend is what happened in C++11) makes writing reliable code far more difficult.
So how to make exceptions opt-out rather than opt-in... the only way is to inspect all the exceptions a piece of code will throw (and the code it uses itself) and then create handlers for each of them, or just wrap all function calls with a generic catch(...) handler which will at least provide a quick and easy way to catch all those exceptions, unless you handle them first. So the best practice is really to write the equivalent of a switch's 'default' case every time.
Yes, and there is a top level catch-all that will terminate the program in any language that has exceptions. That is a fine thing to do, but consider the difference in Common Lisp (at least those implementations I have used): the top level catch-all presents the user with options that are specified by the function which throws the exception. Thus a failed attempt to close a file might give the user a "try again" option, which the user can use after freeing disk space. Clearly such a thing will not always work: the program might be non-interactive, but you can always override this behavior with your own top level catch-all.
As a final thought, the C++ goal of being both high- and low-level has questionable merit. High level programming is only about program logic; low level programming involves some logic, but must also deal with mechanics. Most of the code that is in use today is high level i.e. there is nothing machine-specific about it, it was written to implement a particular abstract algorithm or process. This is true of C++ code as well: most C++ code is high level code. Unfortunately, in order to satisfy the needs of low level programmers, C++ does not provide certain high level features (garbage collection being the most prominent, but also multiple dispatch
And my experience has taught me that you never through an exception you yourself aren't prepared to catch.
That's fine if you have a good way to signal errors to client code. Error codes and return values are lacking in that department, because client code can (and probably will) ignore them.
You seem to be wrongfully blaming deficiencies in Qt's implementation on the langauge
I was originally replying to a post that claimed Qt was the "best" toolkit for writing "high quality" C++ programs. Qt uses error codes, not because error codes are a good thing (they are not), but because Qt is a C++ toolkit and C++ makes anything other than error codes unreliable. How is that an unfair criticism?
I've written numerous pieces of complex software with Qt using exceptions and have never seen an exception fail to be caught or ever let errors go unchecked
Except that preventing exceptions from crashing your program in C++ means preventing some exceptions from propagating -- and basically forces you to create programs that do not handle certain errors. In C++98, you could just risk a double exception fault, but it was considered bad practice; in C++11, you can't even take that risk, and so your destructors either have to handle the error properly or you need to find some other way to signal the error (or else let it go unhandled or just quit). On some level, you are either not using exceptions at all or else you are allowing some exceptions to be ignored -- that's a reality of C++ exception handling.
I've used tons of crappy Java and .Net
Did I say that Java or .NET are better? In all of these systems, exceptions could have been done better -- for example, by not destroying the stack before the exception handler executes. Java won't cause your program to abort when exceptions are thrown, but Java will cause exceptions to be "forgotten" under some circumstances:
That is not much better if you want "high quality" software.
You might want to update your C++ hater points beyond what you read on yosefk.com or other lame whiner sites.
Lame whiner sites? I programmed C++ for a decade, and I still have to write C++ code sometimes. My dislike of the languages comes from experience, not from some website. Error handling is just one issue, one that I think is very much relevant if we are going to talk about "high quality" software. Programming in C++ requires knowledge of the long list of undefined behavior, the long list of patterns that have to be used to avoid that behavior (which hardly anyone deviates from, except for novices who have not yet learned the patterns), and debugging is as much about correcting bad program mechanics as it is about correcting bad program logic (and the majority of C++ code is not low level code).
Yes, I know, programmers should just follow best practices; if that is the case, why not just make those practices standard, and create a special statement to disable that behavior? Why are we forcing programmers to explicitly say, "I do not want this program to crash," when we could be forcing them to be explicit in situations where they do want to write potentially unsafe code?
The problem is that "high quality software" should handle errors -- it should not crash when an error occurs (in the worst case, it should gracefully shut down), and it should not ignore errors. Error codes are fine as long as you actually handle them, but in practice the effort required to check the return value of every function call (and you think checked exceptions are annoying?) leads to some errors not being detected or handled. That is why exceptions are good in theory; but if in practice, an exception can cause a program crash even when there is an exception handler waiting to catch the exception (this is the case in C++), then they are not a good way to deal with errors.
As for embedded systems, if there is enough computational power to display a GUI, I really do not see how exceptions are problematic.
Exception safety is not feature complete! Common cases should work, but classes might still leak or even crash.
And,
Qt itself will not throw exceptions. Instead, error codes are used.
http://qt-project.org/doc/qt-4.8/exceptionsafety.html
Which is not to mention the incoherent uses of exceptions and error codes in the C++ standard library.
C++ toolkit for many high quality applications
There's your problem!
Except that the message is decrypted locally and is not accessible to data mining operations (unless you take the time to send it to them).
Did I say anything about inspections? You do realize that making something illegal, and going around inspecting people's homes for violations, are two very different things right?