It is not just religion, it is any kind of "us vs them" tribalism.
Just remember the "us vs them" is not always the result of tribalism. In this case the "them" are muslim political fundamentalists that will accept no other system in the globe except the Caliphate and Sharia. If you would rather keep your freedoms and the principles of the Englightenment then you fall into the "us" group. These are not "tribes" in the nationalistic sense (which perhaps was what you meant) - it is a fundamental battle of civilizations between those that seek to embrace all cultures, or those that believe that God commands that impose a particular political system be imposed around the globe (and which cannot be questioned). Islam is not alone in this singular view, it just happens to be the most active in it at the moment and is growing more and more active.
Wrong. See this article quoting Victor Cha, GW Bush's top advisor on North Korea:
"All these bags go into the country with the American flag on it and in Korean it says, 'Gift from the American people.' So that is not a bad thing for us in North Korea," he told the hearing.
That is just one article. I original article I read where it was reported that the US flags were everywhere was in Time or Newsweek or one of those. I'll dig it out if you require further proof. I sure the North Koreans try to get the food unlabelled (and may have succeeded now) but that is not what has happened in the past. They really are fuckers.
Interesting. I heard that a Westerner who went through Pyongyang was surprised to see US flags *everywhere*. You see, the food aid extorted from the US comes in large sacks that have US flags stamped on them. When the food is used the sacks get re-purposed for lots of things, like makeshift materials (eg, awnings, window blinds etc). Hence, the North Korean certainly understand where the food is coming from. The official line might be continuous revolution and the evil West, but I doubt the West is hated more than their government (if it wasn't for ruthless armed guards the people would flee - that speaks volumes about what the people think about their 'Workers Paradise').
Of course, the Communists old *said* they were atheists. In every other way they acted like a religion - coopting many of the same mechanisms. However, let us ignore that and follow your argument. Yes the Stalinists were bad atheists, but look around at the World today, there are plenty of good atheists that stand for reason and tolerance. All religions [apart from Jainism, but that's more of a philosophy] on the other hand are fundamentally violent (which is why their fundamentalists are violent). Those who are devout are 'good' at their religion but 'bad' as human beings. For example, bin Laden and team was going back to the violent fundamentals of Islam; David Koresh chose the crazed fundamentals of Christianity.
Now you can argue (as the evil Salafis do) that the problem is that a pure religion has not been implemented, and if it was then it would all be OMG ponies and rainbows and unicorns and stuff. The problem is that a pure religion (at least the Abrahamic ones) contain so many contradictions that by making peace you both follow and oppose the religion. Same for many of the doctrines.
Don't believe me? well take a look at the Skeptic's Annotated Bible (and Qur'an, and Torah). http://skepticsannotatedbible.com/
It shows *in the own words of those books* how parts of them contradict other parts. Not just one or two errors of scribes, but hundreds and hundreds of them. These books are the works of men - originally they were intended to help us, but now they are being used to control us. We have much better morals, and science, and historical knowledge, and health practices, and gender relations, and political systems, and international systems and philosophies than our first attempts at these things as laid out in these books. All the atheists are saying is, "Look these books are written by men who are woefully ignorant by modern standards; we are much smarter now, let us be evidence based for how the universe is and how we conduct ourselves and manage relationships".
Still don't believe me? Here's a pretty graph from Richard Dawkin's own site showing the inconsistencies in the Bible. http://www.project-reason.org/gallery3/image/105/
Again, it is not just a few bugs in the document - the whole thing is fundamentally inconsistent. Once you see such a graph you have to willfully abandon your reason if you want to believe the utterly inconsistent, mindless, and lets face it, evil (incest anyone? genocide anyone) crap in the Bible or it's poor pilagerism, the Qur'an.
The Qur'an fails such an analysis even worse: the Qur'an is often Mo' PBUH making up rules so he could shag women. You see Allah did seem to intervene a lot when he wanted to get married or Aisha busted him shagging one of his other wives out of turn. Note: Aisha was 9 when Mohammed took her virginity - and whatever Mo did is what all Muslims aspire to do - and you think the atheists have it wrong?.
Citation required - well here you go (a humerous slant written by an ex-Muslim) http://kafirgirl.wordpress.com/archive/ Analysis of the Qur'an (by an ex-Muslim) http://kafirgirl.wordpress.com/2008/08/03/wives-part-1/ "Swimmin’ in Women: Mohammed’s wives and concubines. (Part I)" http://kafirgirl.wordpress.com/2008/08/05/wives-part-2/ "Swimmin’ in Women: Mohammed’s wives and concubines. (Part II)" http://kafirgirl.wordpress.com/2008/07/18/chapter4part3/ "The Women (girls, girls, girls)"
You still think the atheists are the bad/immoral guys?
Tumbling out of control also means any directional antennae are useless. If you intend sending commands to the satellite though such an antenna then you might not be able to recover the ability to control the satellite.
The North Korean people aren't just hungry, they are starving en-masse. And the leadership is all into putting its tiny foreign earnings into dick swinging activities like this (achieving what Russia and the US did decades ago). The DPRK really is the most criminal and totalitarian regime out there.
You have a right to privacy. In most countries you must explicitly consent to have personal details given to third parties (although this is often in fine print) or be in a public space with no reasonable expectation of privacy. Your own PC is not a public space and Ubuntu are not asking for your consent in forwarding not only your search results, but likely searches based on the indexed contents of your filesystem.
It is wonderful you serendipitously found a new friend through a breach of your mutual privacy. Now imagine the converse, where you were a girl and didn't want to be found by an abusive ex-boyfriend, or by criminal kidnappers (they do exist) etc etc. The services you *didn't consent to* are working against you in this regard, and there may be no escape from the tracking (particularly as cellphones are the best and easiest tracking devices known to those that watch).
Personally i don't think your one happy coincidence makes up for the potential damage to many that unauthorized privacy breaches do. Furthermore, the companies are breaking the spirit of the law when they onsell your personal information *without you consenting to it* (that's the real key, it's not that they do it, it's that they didn't ask you). Ubuntu have it wrong. This needs to be an opt-in system.
Can't see the problem? what happens when the overridden method doesn't call the parent implementation. You then don't get resource cleanup. Same thing for constructors (don't get the allocation you expect). These are very dangerous so most style guides recommend not to do it (at least in the constructor). Here's a link with a discussion for you to ponder (since Netbeans warns you that overriding in certain methods is bad): http://stackoverflow.com/questions/3404301/whats-wrong-with-overridable-method-calls-in-constructors
FYI: return from finally is described in the Java Language Spec 14.20.2.
Because of the nastiness they banned return from finally in C#. Unfortunately it is not enforced in Java, so it just has to be a matter of style (and pay heed to the warning you get - of course code should be written to avoid warnings, they're there for a reason, yeah?).
Lol. Before I posted I wrote and tested an example myself and got a result where the exception was caught in main (I had a catch clause there). When I try your example I get as you do. So I'll consider myself corrected (see, I'm willing to accept I was wrong, how often does that happen on Slashdot). Of course it is a style mistake to return in finally (just as it is a mistake to use a non-final method in finally or in a constructor). The correct style is there should be a single return should be at the end of the method (which is why lint tools like Findbugs/PMD will whinge when you don't do this) - to make the code readable and possibly to avoid the issue you raised. I hadn't encountered this before because I've never made the mistake of returning in finally, since I try follow the style rules of Findbugs/PMD (got into the 'lint' habit as a C/C++ dev):)
Thanks for the link. The license is not Open Source, which makes it useless for many of us. In fact, because the code is not Free Software we are best to avoid looking at it - there is a world of legal pain to be had if it is proved you copied code or ideas (just ask Google, fortunately Oracle pretty much lost that battle so OpenJDK is in the clear).
I don't get the fire-breathing vitriol directed at Canonical for doing what they do. If you don't like it, you don't have to use their distro.
Canonical would like us to use their distro, yes? Then why should they (or you) be perturbed when customers pronounce loudly that Canonical are making missteps? Now there are always whingers, but there is such a groundswell of opposition of Unity and this privacy breaching move that surely it reflects the will of a significant fraction of users. You may tolerate, or even enjoy, a once fine restaurant now serving swill but surely you might understand that other dinners can express their disappointment, yes? Even for something free we can still complain about privacy breaches. Before you counter with "freeloaders can't complain" please remember that Canonical are perfectly free to charge for Ubuntu, and they themselves also take (and yes, improve) for free the vast amount of upstream work for no cost.
If Canonical want us to use their distro (for which they can leverage rewards in other ways) then making it unappealing helps neither them nor us. It is not the people who complain about Ubuntu that you should worry about, these people feel passionate enough about Ubuntu that they'll complain to try and make it better. The people who can't be bothered to comment and merely switch distros are of greater concern to Ubuntu's viability.
or you can use another distro
That's what I did. I used to recommend and use Ubuntu for my Linux fix, but now I use Mint. However, I made comment not as an ungrateful bleat but because silence helps Canonical far, far less than taking the time to write what we don't like about their direction (changing from something that was far more promising). My tastes have changed far less than their direction has. Do you think it is worth them understanding that? (note: software development firms pay large sums to market research firms for the same information - complaining is a way of giving back, annoying yes, but it is still contributing to those companies willing to listen to their users and adapt to the market).
Thanks for the link. I skimmed it quickly and will read again once I have more time.
To be honest I don't think you can reduce the complexity of error handling that much. The complexity arises not because we don't have the correct keywords but because it is application-specific as to whether an error is recoverable or non-recoverable and for the recoverable cases there are a whole bunch of mitigations that may or may not be applicable. To handle this you need application-specific code. Adding keywords will reduce complexity, but far less than most people think.
Also, my original statements are still valid. In Java you would ordinarily need to write *zero* lines of code to cope with most error conditions. You cannot get more simple than this. The case I was describing is because the standard library, or poorly written user-defined libraries, force you to deal with problems instead of allowing them to propagate through to someone that can handle them (which may be the highest level of the program). The problem is the standard libraries, not the language itself.
Now the associated problem with exception throwing is handling cleanup. Again in Java it should require *zero* lines of code. That is the whole point of the Java garbage collector (GC), to ensure eventual resource release under exceptional and multi-threaded conditions (that is, in non-deterministic situations). For most resources the GC works perfectly. You may choose to release resources sooner for efficiency (eg. closing network connections) or if you are accessing native libraries. A 'using' keyword (like C#) would be handy here. I believe having such a feature is under consideration.
So, I personally think Java as a language has reasonable design for error handling. In general zero extra code needs to be written. Only application-specific handling code needs to be written if the developer chooses to handle and log exceptional conditions (which I would argue is good practice no matter what language you are using, but it is not strictly necessary). Apart from 'using', adding arbitrary keywords is unlikely to help reduce the complexity below the zero lines required at present. So no, it wasn't I missed the point they were trying to make - I simply disagree that adding extra keywords would help (since Java does most reclaimation automatically without programmer intervention). The problem is in the Java libraries, both with checked exceptions forcing the programmer to propagate exceptions they cannot handle (eg. at the current level of a layered system), and in special cases that require manual resource release rather than letting the GC do its job. That is the real problem to be solved (while still retaining Java's fantastic runtime performance - which doesn't matter for many applications, but does happen to matter for mine).
First they totally ignore user wishes by foisting Unity on previously happy Ubuntu users, with a "for your own good" attitude. Thank goodness there is Linux Mint is all I can say about the desktop nonsense.
Now Ubuntu are integrating privacy-destroying searches. Then they have the temerity to criticize the guy who inspired the ecosystem they depend on (and profit from), when he points out that what is good for Canonical is not good for the privacy of their users.
What a tragedy. Ubuntu's focus on ease of use was such a great leap forward for Linux usability. Now they've lost the plot and forgot about their constituency, instead trying to drive more and more revenue with things the user's don't actually want.
It used to be, "In order for Microsoft to 'win', the customer must lose". You could extend that to "In order for Canonical to win, the customer must lose". You could then generalize that (as RMS does) to "In order for $COMPANY to win, the customer must lose". There are still some companies around that actually care about their employees and users (not just paying lip service to it), but that number is clearly decreasing. RMS is right to call them out for ignoring user desire for privacy (privacy should be the default, with effort to opt-in).
Jono has what seems a reasonable post. He never addresses RMS' assertion not that searches go to Amazon, but that your files and folders that are also searched also have metadata submitted to Canonical (and then presumably, portions go to Amazon). Jono never dismisses this citing stuff about "personal preference" instead. It would be nice if Canonical came out with a statement saying that they don't transfer information from your searched files and folders to Amazon, because they haven't yet (at least not in my reading of Jono's post). Until Canonical prove otherwise it appear that RMS is completely right in this issue.
Oops, I'm half asleep today. The line "do the "right' thing by ignoring the exception." should instead refer to ignoring the return statement if an exception is raised. Apologies. Hopefully it makes more sense now.
You are correct. If you re-look at my example you'll see I transform the exception before throwing. The finally clause is executed but the return is not. The exception still propagates (which is why you can use finally in the presence of exceptions). In addition, you'll find you get a warning that "finally does not complete normally" to indicate there is a problem (at least I do in Eclipse).
So, I think you are a bit confused. Firstly, I don't advocate suppressing the exception, I advocate transforming and re-throwing. If an exception was happening on cleanup and we were to suppress it then it should be fully logged. Never simply annihilated.
Secondly, you seem to think that the return in the finally will 'trump' the exception. It doesn't. Fortunately the Java designers and compiler writers foresaw this and do the 'right' thing by ignoring the exception. Therefore, my example still stands (provided you either throw and exception wrapping the cause, re-throw the original exception, or log the suppressed exception were you have 'handled' it). This is not hard:)
To solve the "how do I let the caller know what they can safely do problem" I use the @throws Javadoc tag. Usually I've have several @throws tags for the IllegalArgumentExceptions that can get raised, and some @throws IllegalStateException if some set-up or required previous method call has not been done.
If you need to pass additional data back I'll just make an RuntimeException derived class of my own and add in the required properties. I'll even add in an enumeration of the reasons the exception is raised so I can pass causes back through webservices and have the client decide which enums they can handle and which enums they'll just log and abort the attempted operation. While enum error codes are discouraged when not using exceptions I find then convenient attached to exceptions as they provide nuances for making decisions on when handling runtime exceptions. In this case error code enums allow decision making without needing to create a whole class hierarchy of exceptions (a somewhat old fashioned and clunky way of doing the same thing, but requires a lot more lines of boilerplate code, and swells the number of classes you have to deal with).
The idea of using RuntimeExceptions rather than checked exceptions is that the caller doesn't have to think about conditions they can't handle or recover from, not that they don't think about error handling at all (if you are checking preconditions and consistent state everywhere it will in your thinking anyway).
The idea is to keep it all as lightweight. The client of your library doesn't have to deal with exceptions they have no chance of handling (eg. most resource exhaustion issues), but can easily see what not to do to avoid raising exceptions with the arguments they supply (because the JavaDoc tells them which objects can and cannot be null or blank/non-empty strings, what are valid ranges of values etc etc). Besides explaining the intent and responsibilities ('contract') of a method, what the caller can do that would cause the method to fail, the JavaDoc also needs to explain what units a parameter is in: is it in meters, feet, kilometers, nautical miles; is accrued interest for a period of days, months, a quarter, annual, etc. That's what makes the JavaDoc so useful and so important, and why good programmers also fuss about getting their JavaDoc right:)
With regard to using exceptions for 'signalling'. Exceptions are supposed to be 'exceptional'. It is generally considered bad style to use them for flow control since alternatives designed for the purpose exist. Break/continue and labelled goto are all designed for doing that.
Java can be crufty, but it can be made lightweight (less of a hassle to use, JavaBeans designed for ease of use), very robust, and easy to re-use (good Javadoc and JavaBeans). Unfortunately, most examples of Java are trying to demonstrate complex techniques rather than emphasizing that the code should be kept as simple and lightweight as one can manage (which is the real art of design).
I agree, C# is a nice language. The failure of C# is that *the libraries* are not cross-platform. Note that the Mono libraries are not used by the majority of C# developers, and the Mono libraries are incomplete compared to the Microsoft ones, and will never be complete according to the Mono roadmap.
With the world becoming more and more heterogenous with regard to CPU (ARM & x86/64), Operating System (Linux, Android, Mac, Windows) and environment (embedded, rich client and web) then cross-platform matters more than ever.
The language benefits of C# over Java do not compensate for the massive superiority of Java for cross-platform development due to the huge number of fully cross-platform Java libraries. This is why forward-looking people prefer Java, despite the fact that C# has a few nice constructs. Does that make sense?
What you have written was the theory. In practice checked exceptions are painful to use. It is far better to use unchecked exceptions unless you are writing a system where failure is catastrophic, in which case checked exceptions are a useful cross-check on your code, despite the large burden they impose.
This is a fallacy. The code shows how the problem is solved. The documentation describes the intent of the program - this is not the same thing. If the code is wrong the documentation describing the intent allows you to pick up the inconsistency, and what should actually be happening.
Yes, the documentation can also be wrong, and needs to be maintained as much as code and program data. It is part of our jobs to keep all the resources accurate and useful, including the documented *intent*. Anyone who says different is a lousy developer (most probably because they mistake the purpose of documentation, so under value it - or have never been given great documentation that saved them oodles of time).
My example was intended to be more representative of real code where you chain exceptions.
What now? Only call private methods in catch and finally? Wrap everything in a second try block? That's turtles all the way down
Yes, avoid having overridable methods in cleanup. The same applies to constructors (a principle you may be more familiar with). I do use a second try block if I have to. Generally I catch, log in full, and then supress clean up errors; they are not significant to the operation of the program. At the end of the clean up catch I re-throw the original exception, because that is the exception that matters.
"Turtles all the way down" is a possibility but I've never seen more than two exceptions deep in practice. IMHO the problem wih most programs/programmers is they don't look for potential exception causing problems early enough. If you code is thoroughly unit/integratation tested there are only two conditions that can then cause your program to fail:
1) bad input data, or
2) resource failure of some kind (bad disk, bad network, out of memory etc).
Bad data
The bad data is easily handled by checking preconditions of your program: validating all input data at the point it is received, read from file/database/network (throw IllegalArgumentException here); also checking preconditions before use that combinations of data that were not actually bad are consistent and the operation you are about to perform will not fail due to the data it is given (throw IllegalStateException here). If you look for bad data *before* you make any modifying operations you can roll back to a consistent and safe state easily. Your cleanup is often trivial because you detected the issue before you modifed state, not half-way through.
Resource exhaustion
Resource exhaustion can happen at any time, the best thing to do there is go back to a safe state (consistent data) and try and release resources. Thn try again. If you can't release resources then you have to abort the operation or abort the program. If you log the problem in a very clear manner some wetware can come along and correct the environment before trying again. This is why I mentioned good messages in logging is so important.
Safe states
We all know that the operations of software transistion the system from state to state. In a well-tested system any state that is attempted can fail for either of the reasons I pointed out: bad (insufficient or contradictory) data, or environmental/resource problems. The important thing is that if the attempted operation fails and the transition is aborted then the system is returned to a consistent state. In almost all cases this can be achieved by ensuring that the needed resources and data are acquired before any writes are made. It is not always the case this is so, but it very often is. Because this is true the "turtles all the way down" rarely happens (well, hasn't on any of the huge projects I've been on). More importantly, the existing constructs we have are more than sufficient in the vast majority of cases. Yes, you occasionally get nested catches but this is quite rare in my experience (programs doing millions and millions of transactions with all interconnects with all sorts of external devices and systems).
Things developers can do
So, what we can do as developers is:
* unit and integration test with good coverage
* validate all input data at the point we receive it (we can't use it until it is validated)
* check preconditions that before we attempt any operation we have sufficient and consistent data, plus have acquired any required resources (files, memory, network) as much as we can
* assume our operation can fail for any reason, and try and recover back to a consistent/safe state. Autorecovery is an often an option (eg. automatically re-attempting a network or database operation in the failure is likely to have been due a transit
I agree with you. The editor is too simplistic. Why you want to have more than just a single global error handler is that you want to provide information so the caller can make decisions about what they can handle and what they can't handle based on the precise reason for the failure.
In your file example the file might not be able to be opened for many reasons, like: it doesn't exist; the user doesn't have permission to open it; the file is locked by another process etc. Depending on the cause the application can then make decisions whether to: create the file; prompt the user to increase priviledge and then access the file; modify the file's permissions; or release the lock held in another thread and try again; or, just give up completely, recover to a safe state (eg. before the operation was attempted) and then log the operating and file that caused the problem so it can be diagnosed and fixed later.
To me it is shocking that the editor would propose so simplistic solution. If he was working on real-life programs that had to be reliable (instead of tinkering with toy programs for his column, which perhaps could be the case) then he would know that having the ability to distinguish exceptions by type and cause can be very useful for sensible error handling *and recovery*. Now I don't mean by this that every program must have a complex user-defined exception hierarchy, in fact I think that this is almost never warranted, but it can be useful in some cases (although a simple user defined exception with enumerated cause code works just as well as a class based hierarchy, but is much simpler).
In Java you probably wouldn't do as you say. You would 'chain the exception; so that the original exception information is preserved even though you are transforming the exception type (eg. from a checked exception thrown from a library to an unchecked exception you don't have to declare throws clauses for). The code becomes:
try { // Do something here that may throw an exception (which is 'checked'). // eg. throw Exception();
} catch (Throwable th) {
throw new RuntimeException("A problem occurred when launching the SS-18 because the launch authorization code was invalid. The launch authorization code had a value of " + authCode, th);
} finally { // Do any clean-up.
}
There are two import things to note in this contrived example:
* The use of the chained exception. When the exception type is transformed by the creation of the new exception we include the old exception in the constructor. That way the 'chain' of exceptions can be viewed and the original cause of the exception found. That will help you fix this issue.
* A message that tries to describe the exact decision used to throw the exception and the values of any contributing variables or boundary values. It is critical this information is recorded at the point of throwing because in a massively multithreaded system with millions of transactions you can't reproduce the same conditions exactly in your debugger. The only information you have is what you put in your log, and you must include all relevant information in that log. Otherwise you will not have enough data to diagnose the decision the program made to throw, and won't have enough info to fix the problem.
Checked exceptions are valuable in Java. Those that are against them don't understand that they are very useful for certain classes of problems - systems that have to be reliable. The mistake the Java designers made was that they made the library throw checked exceptions rather than unchecked ones. If they had used unchecked exceptions everywhere (while still supporting checked exceptions for systems that need to force reliable operation under error conditions) then many of the gripes people have when encountering Java would be eliminated. Plus, programmer productively would increase because we wouldn't have to wrap and chain the checked exceptions produced by library calls all over the place. C# kinda gets it right in the fact the libraries don't have/use checked exceptions, but it lacks the option of using checked exceptions in critical systems. So neither Java nor C# have it perfect, IMHO.
If you are a Java developer writing libraries intended for re-use by others then you should ensure your library never throws a checked exception to the caller. Only libraries for critical systems should do this. Unless you are working on nuclear plant control, avionics, medical devices, weapons systems or interplanetary probes then your system probably doesn't need to expose checked exceptions.
The way you structure, handle and report exceptions is mundane, but is absolutely crucial for writing reliable and easily maintained software. Most programmers are sloppy about this, or consider it as unimportant as good documentation, but that is what makes then bad programmers (if you ever have to use or maintain their software).
I hope this helps some developers out there understand how to use chained exceptions. The chaining *preserves information* about the cause of a failure. The adding sensible messages and program state is also about *preserving information* about the failure at the point of throw. Loss of information is what you are battling here, since once you lose/throw away information it is a huge effort to reconstruct it later. Avoiding loss of information is worth keeping that in mind as you develop, so you avoid doing it. Example: the built in NullPointerException being the worst example of providing zero additional information about what was null, a problem if you have multiple chained method calls on a single line. Don't write code like the Java code that raises NullPointerException.
I'll step out now as you've merely descended into another mindless rant laced with insults, and more lies and falsehoods.
Please do.
If you can't see why the rise of the far right through politics in nations with some of the highest defence expenditure in the world and nuclear weapons fitted on global delivery systems (Britain, Russia, and France) is a bigger threat than a bunch of angry people living in abject poverty in nations like Saudi Arabia whose military is only a signature in the Whitehouse away from losing the funding it requires to survive turning the nation and it's leadership into the latest target of the arab spring then you really aren't capable of having this discussion.
These countries are powerful but *regional* players. As a European they loom large for you - but for most of the rest of the world they are insignificant. They don't matter a whit on the *global* stage because their power projection is limited, and they don't have the will to dominate the globe. What matters is who is most likely to reach out and affect ordinary people in the places they live and work, or when they travel. The relative insignificance of Britain, France and Russia is of the same order as China, which is the regional nuisance here (with its neighbours getting bullied by its imperialist agenda in the South China Sea, which is real, unlike your theoretical postulations).
Certainly a country taken over by the far right would be very bad. I don't think it is very likely in Britain or France. Yes, the right gets in but they usually become centralised slightly once in office. Plus, in order to implement your fears they need to eliminate their political opposition. It's just not going to happen in the way it did 80 years ago. In Russia, well they've always been dodgy and they are destroying any moderating opposition. However, the probability of this happening is still lower than other threats that are already in motion - and the US still has the power to cotain Russia (the US defensive missile program gives more options without having to resort to MAD, and the Russians know this which is a good restraining factor).
It's just a shame that you have become exactly what you claim to preach against - an extremist, and that what you claim to argue for, internet freedom, you don't actually want.
Utter codswallop! You keep projecting attributes on to me that are assumed and completely false (just like your complete ignorance of New Zealand, and then the clueless insulting of a country and its inhabitants you have little real idea about; at least I've been to Britain numerous times, have you ever been to NZ and seen how diverse and inclusive it is?). Unfortunately it appears your mode of debating is to continually project strawmen on to people, and then knock your projection down. It appears you still have not listened to the (progressive, not fascist!) references I keep talking about (and I keep talking about them because your strawmen would be destroyed if you did the research - and then we could progress the debate in a rational and informed manner).
I'm not an extremist at all, I simply follow the line of reasoning of esteemed progressive thinkers like Hitchens, Dawkins, Harris (and the slightly more rabid, but factually correct Condell). But please don't let me spoil your (dare I say, extreme) delusions about an imminent return of imperialistic fascism or your delight in characterising someone trying to get you to do some *basic research* as an extremist:)
Slashdot Mirror
It is not just religion, it is any kind of "us vs them" tribalism.
Just remember the "us vs them" is not always the result of tribalism. In this case the "them" are muslim political fundamentalists that will accept no other system in the globe except the Caliphate and Sharia. If you would rather keep your freedoms and the principles of the Englightenment then you fall into the "us" group. These are not "tribes" in the nationalistic sense (which perhaps was what you meant) - it is a fundamental battle of civilizations between those that seek to embrace all cultures, or those that believe that God commands that impose a particular political system be imposed around the globe (and which cannot be questioned). Islam is not alone in this singular view, it just happens to be the most active in it at the moment and is growing more and more active.
Wrong. See this article quoting Victor Cha, GW Bush's top advisor on North Korea:
"All these bags go into the country with the American flag on it and in Korean it says, 'Gift from the American people.' So that is not a bad thing for us in North Korea," he told the hearing.
http://www.alternet.org/rss/breaking_news/515569/us_lawmakers_oppose_n.korea_food_aid
That is just one article. I original article I read where it was reported that the US flags were everywhere was in Time or Newsweek or one of those. I'll dig it out if you require further proof. I sure the North Koreans try to get the food unlabelled (and may have succeeded now) but that is not what has happened in the past. They really are fuckers.
Interesting. I heard that a Westerner who went through Pyongyang was surprised to see US flags *everywhere*. You see, the food aid extorted from the US comes in large sacks that have US flags stamped on them. When the food is used the sacks get re-purposed for lots of things, like makeshift materials (eg, awnings, window blinds etc). Hence, the North Korean certainly understand where the food is coming from. The official line might be continuous revolution and the evil West, but I doubt the West is hated more than their government (if it wasn't for ruthless armed guards the people would flee - that speaks volumes about what the people think about their 'Workers Paradise').
Of course, the Communists old *said* they were atheists. In every other way they acted like a religion - coopting many of the same mechanisms. However, let us ignore that and follow your argument. Yes the Stalinists were bad atheists, but look around at the World today, there are plenty of good atheists that stand for reason and tolerance. All religions [apart from Jainism, but that's more of a philosophy] on the other hand are fundamentally violent (which is why their fundamentalists are violent). Those who are devout are 'good' at their religion but 'bad' as human beings. For example, bin Laden and team was going back to the violent fundamentals of Islam; David Koresh chose the crazed fundamentals of Christianity.
Now you can argue (as the evil Salafis do) that the problem is that a pure religion has not been implemented, and if it was then it would all be OMG ponies and rainbows and unicorns and stuff. The problem is that a pure religion (at least the Abrahamic ones) contain so many contradictions that by making peace you both follow and oppose the religion. Same for many of the doctrines.
Don't believe me? well take a look at the Skeptic's Annotated Bible (and Qur'an, and Torah). http://skepticsannotatedbible.com/
It shows *in the own words of those books* how parts of them contradict other parts. Not just one or two errors of scribes, but hundreds and hundreds of them. These books are the works of men - originally they were intended to help us, but now they are being used to control us. We have much better morals, and science, and historical knowledge, and health practices, and gender relations, and political systems, and international systems and philosophies than our first attempts at these things as laid out in these books. All the atheists are saying is, "Look these books are written by men who are woefully ignorant by modern standards; we are much smarter now, let us be evidence based for how the universe is and how we conduct ourselves and manage relationships".
Still don't believe me? Here's a pretty graph from Richard Dawkin's own site showing the inconsistencies in the Bible.
http://www.project-reason.org/gallery3/image/105/ Again, it is not just a few bugs in the document - the whole thing is fundamentally inconsistent. Once you see such a graph you have to willfully abandon your reason if you want to believe the utterly inconsistent, mindless, and lets face it, evil (incest anyone? genocide anyone) crap in the Bible or it's poor pilagerism, the Qur'an.
The Qur'an fails such an analysis even worse: the Qur'an is often Mo' PBUH making up rules so he could shag women. You see Allah did seem to intervene a lot when he wanted to get married or Aisha busted him shagging one of his other wives out of turn. Note: Aisha was 9 when Mohammed took her virginity - and whatever Mo did is what all Muslims aspire to do - and you think the atheists have it wrong?.
Citation required - well here you go (a humerous slant written by an ex-Muslim)
http://kafirgirl.wordpress.com/archive/ Analysis of the Qur'an (by an ex-Muslim)
http://kafirgirl.wordpress.com/2008/08/03/wives-part-1/ "Swimmin’ in Women: Mohammed’s wives and concubines. (Part I)"
http://kafirgirl.wordpress.com/2008/08/05/wives-part-2/ "Swimmin’ in Women: Mohammed’s wives and concubines. (Part II)"
http://kafirgirl.wordpress.com/2008/07/18/chapter4part3/ "The Women (girls, girls, girls)"
You still think the atheists are the bad/immoral guys?
No mod points at moment - but awesome! I hope you're playing all week :)
Tumbling out of control also means any directional antennae are useless. If you intend sending commands to the satellite though such an antenna then you might not be able to recover the ability to control the satellite.
The North Korean people aren't just hungry, they are starving en-masse. And the leadership is all into putting its tiny foreign earnings into dick swinging activities like this (achieving what Russia and the US did decades ago). The DPRK really is the most criminal and totalitarian regime out there.
You have a right to privacy. In most countries you must explicitly consent to have personal details given to third parties (although this is often in fine print) or be in a public space with no reasonable expectation of privacy. Your own PC is not a public space and Ubuntu are not asking for your consent in forwarding not only your search results, but likely searches based on the indexed contents of your filesystem.
It is wonderful you serendipitously found a new friend through a breach of your mutual privacy. Now imagine the converse, where you were a girl and didn't want to be found by an abusive ex-boyfriend, or by criminal kidnappers (they do exist) etc etc. The services you *didn't consent to* are working against you in this regard, and there may be no escape from the tracking (particularly as cellphones are the best and easiest tracking devices known to those that watch).
Personally i don't think your one happy coincidence makes up for the potential damage to many that unauthorized privacy breaches do. Furthermore, the companies are breaking the spirit of the law when they onsell your personal information *without you consenting to it* (that's the real key, it's not that they do it, it's that they didn't ask you). Ubuntu have it wrong. This needs to be an opt-in system.
Can't see the problem? what happens when the overridden method doesn't call the parent implementation. You then don't get resource cleanup. Same thing for constructors (don't get the allocation you expect). These are very dangerous so most style guides recommend not to do it (at least in the constructor). Here's a link with a discussion for you to ponder (since Netbeans warns you that overriding in certain methods is bad):
http://stackoverflow.com/questions/3404301/whats-wrong-with-overridable-method-calls-in-constructors
It is a recognized problem. It is more well known that a non-final should not be used in a constructor - perhaps you've heard of this?
FYI: return from finally is described in the Java Language Spec 14.20.2.
Because of the nastiness they banned return from finally in C#. Unfortunately it is not enforced in Java, so it just has to be a matter of style (and pay heed to the warning you get - of course code should be written to avoid warnings, they're there for a reason, yeah?).
Lol. Before I posted I wrote and tested an example myself and got a result where the exception was caught in main (I had a catch clause there). When I try your example I get as you do. So I'll consider myself corrected (see, I'm willing to accept I was wrong, how often does that happen on Slashdot). Of course it is a style mistake to return in finally (just as it is a mistake to use a non-final method in finally or in a constructor). The correct style is there should be a single return should be at the end of the method (which is why lint tools like Findbugs/PMD will whinge when you don't do this) - to make the code readable and possibly to avoid the issue you raised. I hadn't encountered this before because I've never made the mistake of returning in finally, since I try follow the style rules of Findbugs/PMD (got into the 'lint' habit as a C/C++ dev) :)
Thanks for the link. The license is not Open Source, which makes it useless for many of us. In fact, because the code is not Free Software we are best to avoid looking at it - there is a world of legal pain to be had if it is proved you copied code or ideas (just ask Google, fortunately Oracle pretty much lost that battle so OpenJDK is in the clear).
I don't get the fire-breathing vitriol directed at Canonical for doing what they do. If you don't like it, you don't have to use their distro.
Canonical would like us to use their distro, yes? Then why should they (or you) be perturbed when customers pronounce loudly that Canonical are making missteps? Now there are always whingers, but there is such a groundswell of opposition of Unity and this privacy breaching move that surely it reflects the will of a significant fraction of users. You may tolerate, or even enjoy, a once fine restaurant now serving swill but surely you might understand that other dinners can express their disappointment, yes? Even for something free we can still complain about privacy breaches. Before you counter with "freeloaders can't complain" please remember that Canonical are perfectly free to charge for Ubuntu, and they themselves also take (and yes, improve) for free the vast amount of upstream work for no cost.
If Canonical want us to use their distro (for which they can leverage rewards in other ways) then making it unappealing helps neither them nor us. It is not the people who complain about Ubuntu that you should worry about, these people feel passionate enough about Ubuntu that they'll complain to try and make it better. The people who can't be bothered to comment and merely switch distros are of greater concern to Ubuntu's viability.
or you can use another distro
That's what I did. I used to recommend and use Ubuntu for my Linux fix, but now I use Mint. However, I made comment not as an ungrateful bleat but because silence helps Canonical far, far less than taking the time to write what we don't like about their direction (changing from something that was far more promising). My tastes have changed far less than their direction has. Do you think it is worth them understanding that? (note: software development firms pay large sums to market research firms for the same information - complaining is a way of giving back, annoying yes, but it is still contributing to those companies willing to listen to their users and adapt to the market).
Thanks for the link. I skimmed it quickly and will read again once I have more time.
To be honest I don't think you can reduce the complexity of error handling that much. The complexity arises not because we don't have the correct keywords but because it is application-specific as to whether an error is recoverable or non-recoverable and for the recoverable cases there are a whole bunch of mitigations that may or may not be applicable. To handle this you need application-specific code. Adding keywords will reduce complexity, but far less than most people think.
Also, my original statements are still valid. In Java you would ordinarily need to write *zero* lines of code to cope with most error conditions. You cannot get more simple than this. The case I was describing is because the standard library, or poorly written user-defined libraries, force you to deal with problems instead of allowing them to propagate through to someone that can handle them (which may be the highest level of the program). The problem is the standard libraries, not the language itself.
Now the associated problem with exception throwing is handling cleanup. Again in Java it should require *zero* lines of code. That is the whole point of the Java garbage collector (GC), to ensure eventual resource release under exceptional and multi-threaded conditions (that is, in non-deterministic situations). For most resources the GC works perfectly. You may choose to release resources sooner for efficiency (eg. closing network connections) or if you are accessing native libraries. A 'using' keyword (like C#) would be handy here. I believe having such a feature is under consideration.
So, I personally think Java as a language has reasonable design for error handling. In general zero extra code needs to be written. Only application-specific handling code needs to be written if the developer chooses to handle and log exceptional conditions (which I would argue is good practice no matter what language you are using, but it is not strictly necessary). Apart from 'using', adding arbitrary keywords is unlikely to help reduce the complexity below the zero lines required at present. So no, it wasn't I missed the point they were trying to make - I simply disagree that adding extra keywords would help (since Java does most reclaimation automatically without programmer intervention). The problem is in the Java libraries, both with checked exceptions forcing the programmer to propagate exceptions they cannot handle (eg. at the current level of a layered system), and in special cases that require manual resource release rather than letting the GC do its job. That is the real problem to be solved (while still retaining Java's fantastic runtime performance - which doesn't matter for many applications, but does happen to matter for mine).
First they totally ignore user wishes by foisting Unity on previously happy Ubuntu users, with a "for your own good" attitude. Thank goodness there is Linux Mint is all I can say about the desktop nonsense.
Now Ubuntu are integrating privacy-destroying searches. Then they have the temerity to criticize the guy who inspired the ecosystem they depend on (and profit from), when he points out that what is good for Canonical is not good for the privacy of their users.
What a tragedy. Ubuntu's focus on ease of use was such a great leap forward for Linux usability. Now they've lost the plot and forgot about their constituency, instead trying to drive more and more revenue with things the user's don't actually want.
It used to be, "In order for Microsoft to 'win', the customer must lose". You could extend that to "In order for Canonical to win, the customer must lose". You could then generalize that (as RMS does) to "In order for $COMPANY to win, the customer must lose". There are still some companies around that actually care about their employees and users (not just paying lip service to it), but that number is clearly decreasing. RMS is right to call them out for ignoring user desire for privacy (privacy should be the default, with effort to opt-in).
Jono has what seems a reasonable post. He never addresses RMS' assertion not that searches go to Amazon, but that your files and folders that are also searched also have metadata submitted to Canonical (and then presumably, portions go to Amazon). Jono never dismisses this citing stuff about "personal preference" instead. It would be nice if Canonical came out with a statement saying that they don't transfer information from your searched files and folders to Amazon, because they haven't yet (at least not in my reading of Jono's post). Until Canonical prove otherwise it appear that RMS is completely right in this issue.
Oops, I'm half asleep today. The line "do the "right' thing by ignoring the exception." should instead refer to ignoring the return statement if an exception is raised. Apologies. Hopefully it makes more sense now.
You are correct. If you re-look at my example you'll see I transform the exception before throwing. The finally clause is executed but the return is not. The exception still propagates (which is why you can use finally in the presence of exceptions). In addition, you'll find you get a warning that "finally does not complete normally" to indicate there is a problem (at least I do in Eclipse).
So, I think you are a bit confused. Firstly, I don't advocate suppressing the exception, I advocate transforming and re-throwing. If an exception was happening on cleanup and we were to suppress it then it should be fully logged. Never simply annihilated.
Secondly, you seem to think that the return in the finally will 'trump' the exception. It doesn't. Fortunately the Java designers and compiler writers foresaw this and do the 'right' thing by ignoring the exception. Therefore, my example still stands (provided you either throw and exception wrapping the cause, re-throw the original exception, or log the suppressed exception were you have 'handled' it). This is not hard :)
Interesting ideas.
To solve the "how do I let the caller know what they can safely do problem" I use the @throws Javadoc tag. Usually I've have several @throws tags for the IllegalArgumentExceptions that can get raised, and some @throws IllegalStateException if some set-up or required previous method call has not been done.
If you need to pass additional data back I'll just make an RuntimeException derived class of my own and add in the required properties. I'll even add in an enumeration of the reasons the exception is raised so I can pass causes back through webservices and have the client decide which enums they can handle and which enums they'll just log and abort the attempted operation. While enum error codes are discouraged when not using exceptions I find then convenient attached to exceptions as they provide nuances for making decisions on when handling runtime exceptions. In this case error code enums allow decision making without needing to create a whole class hierarchy of exceptions (a somewhat old fashioned and clunky way of doing the same thing, but requires a lot more lines of boilerplate code, and swells the number of classes you have to deal with).
The idea of using RuntimeExceptions rather than checked exceptions is that the caller doesn't have to think about conditions they can't handle or recover from, not that they don't think about error handling at all (if you are checking preconditions and consistent state everywhere it will in your thinking anyway).
The idea is to keep it all as lightweight. The client of your library doesn't have to deal with exceptions they have no chance of handling (eg. most resource exhaustion issues), but can easily see what not to do to avoid raising exceptions with the arguments they supply (because the JavaDoc tells them which objects can and cannot be null or blank/non-empty strings, what are valid ranges of values etc etc). Besides explaining the intent and responsibilities ('contract') of a method, what the caller can do that would cause the method to fail, the JavaDoc also needs to explain what units a parameter is in: is it in meters, feet, kilometers, nautical miles; is accrued interest for a period of days, months, a quarter, annual, etc. That's what makes the JavaDoc so useful and so important, and why good programmers also fuss about getting their JavaDoc right :)
With regard to using exceptions for 'signalling'. Exceptions are supposed to be 'exceptional'. It is generally considered bad style to use them for flow control since alternatives designed for the purpose exist. Break/continue and labelled goto are all designed for doing that.
Java can be crufty, but it can be made lightweight (less of a hassle to use, JavaBeans designed for ease of use), very robust, and easy to re-use (good Javadoc and JavaBeans). Unfortunately, most examples of Java are trying to demonstrate complex techniques rather than emphasizing that the code should be kept as simple and lightweight as one can manage (which is the real art of design).
I agree, C# is a nice language. The failure of C# is that *the libraries* are not cross-platform. Note that the Mono libraries are not used by the majority of C# developers, and the Mono libraries are incomplete compared to the Microsoft ones, and will never be complete according to the Mono roadmap.
With the world becoming more and more heterogenous with regard to CPU (ARM & x86/64), Operating System (Linux, Android, Mac, Windows) and environment (embedded, rich client and web) then cross-platform matters more than ever.
The language benefits of C# over Java do not compensate for the massive superiority of Java for cross-platform development due to the huge number of fully cross-platform Java libraries. This is why forward-looking people prefer Java, despite the fact that C# has a few nice constructs. Does that make sense?
What you have written was the theory. In practice checked exceptions are painful to use. It is far better to use unchecked exceptions unless you are writing a system where failure is catastrophic, in which case checked exceptions are a useful cross-check on your code, despite the large burden they impose.
This is a fallacy. The code shows how the problem is solved. The documentation describes the intent of the program - this is not the same thing. If the code is wrong the documentation describing the intent allows you to pick up the inconsistency, and what should actually be happening.
Yes, the documentation can also be wrong, and needs to be maintained as much as code and program data. It is part of our jobs to keep all the resources accurate and useful, including the documented *intent*. Anyone who says different is a lousy developer (most probably because they mistake the purpose of documentation, so under value it - or have never been given great documentation that saved them oodles of time).
My example was intended to be more representative of real code where you chain exceptions.
What now? Only call private methods in catch and finally? Wrap everything in a second try block? That's turtles all the way down
Yes, avoid having overridable methods in cleanup. The same applies to constructors (a principle you may be more familiar with). I do use a second try block if I have to. Generally I catch, log in full, and then supress clean up errors; they are not significant to the operation of the program. At the end of the clean up catch I re-throw the original exception, because that is the exception that matters.
"Turtles all the way down" is a possibility but I've never seen more than two exceptions deep in practice. IMHO the problem wih most programs/programmers is they don't look for potential exception causing problems early enough. If you code is thoroughly unit/integratation tested there are only two conditions that can then cause your program to fail:
Bad data
The bad data is easily handled by checking preconditions of your program: validating all input data at the point it is received, read from file/database/network (throw IllegalArgumentException here); also checking preconditions before use that combinations of data that were not actually bad are consistent and the operation you are about to perform will not fail due to the data it is given (throw IllegalStateException here). If you look for bad data *before* you make any modifying operations you can roll back to a consistent and safe state easily. Your cleanup is often trivial because you detected the issue before you modifed state, not half-way through.
Resource exhaustion
Resource exhaustion can happen at any time, the best thing to do there is go back to a safe state (consistent data) and try and release resources. Thn try again. If you can't release resources then you have to abort the operation or abort the program. If you log the problem in a very clear manner some wetware can come along and correct the environment before trying again. This is why I mentioned good messages in logging is so important.
Safe states
We all know that the operations of software transistion the system from state to state. In a well-tested system any state that is attempted can fail for either of the reasons I pointed out: bad (insufficient or contradictory) data, or environmental/resource problems. The important thing is that if the attempted operation fails and the transition is aborted then the system is returned to a consistent state. In almost all cases this can be achieved by ensuring that the needed resources and data are acquired before any writes are made. It is not always the case this is so, but it very often is. Because this is true the "turtles all the way down" rarely happens (well, hasn't on any of the huge projects I've been on). More importantly, the existing constructs we have are more than sufficient in the vast majority of cases. Yes, you occasionally get nested catches but this is quite rare in my experience (programs doing millions and millions of transactions with all interconnects with all sorts of external devices and systems).
Things developers can do
So, what we can do as developers is:
I agree with you. The editor is too simplistic. Why you want to have more than just a single global error handler is that you want to provide information so the caller can make decisions about what they can handle and what they can't handle based on the precise reason for the failure.
In your file example the file might not be able to be opened for many reasons, like: it doesn't exist; the user doesn't have permission to open it; the file is locked by another process etc. Depending on the cause the application can then make decisions whether to: create the file; prompt the user to increase priviledge and then access the file; modify the file's permissions; or release the lock held in another thread and try again; or, just give up completely, recover to a safe state (eg. before the operation was attempted) and then log the operating and file that caused the problem so it can be diagnosed and fixed later.
To me it is shocking that the editor would propose so simplistic solution. If he was working on real-life programs that had to be reliable (instead of tinkering with toy programs for his column, which perhaps could be the case) then he would know that having the ability to distinguish exceptions by type and cause can be very useful for sensible error handling *and recovery*. Now I don't mean by this that every program must have a complex user-defined exception hierarchy, in fact I think that this is almost never warranted, but it can be useful in some cases (although a simple user defined exception with enumerated cause code works just as well as a class based hierarchy, but is much simpler).
In Java you probably wouldn't do as you say. You would 'chain the exception; so that the original exception information is preserved even though you are transforming the exception type (eg. from a checked exception thrown from a library to an unchecked exception you don't have to declare throws clauses for). The code becomes:
try {
// Do something here that may throw an exception (which is 'checked').
// eg. throw Exception();
// Do any clean-up.
} catch (Throwable th) {
throw new RuntimeException("A problem occurred when launching the SS-18 because the launch authorization code was invalid. The launch authorization code had a value of " + authCode, th);
} finally {
}
There are two import things to note in this contrived example:
Checked exceptions are valuable in Java. Those that are against them don't understand that they are very useful for certain classes of problems - systems that have to be reliable. The mistake the Java designers made was that they made the library throw checked exceptions rather than unchecked ones. If they had used unchecked exceptions everywhere (while still supporting checked exceptions for systems that need to force reliable operation under error conditions) then many of the gripes people have when encountering Java would be eliminated. Plus, programmer productively would increase because we wouldn't have to wrap and chain the checked exceptions produced by library calls all over the place. C# kinda gets it right in the fact the libraries don't have/use checked exceptions, but it lacks the option of using checked exceptions in critical systems. So neither Java nor C# have it perfect, IMHO.
If you are a Java developer writing libraries intended for re-use by others then you should ensure your library never throws a checked exception to the caller. Only libraries for critical systems should do this. Unless you are working on nuclear plant control, avionics, medical devices, weapons systems or interplanetary probes then your system probably doesn't need to expose checked exceptions.
The way you structure, handle and report exceptions is mundane, but is absolutely crucial for writing reliable and easily maintained software. Most programmers are sloppy about this, or consider it as unimportant as good documentation, but that is what makes then bad programmers (if you ever have to use or maintain their software).
I hope this helps some developers out there understand how to use chained exceptions. The chaining *preserves information* about the cause of a failure. The adding sensible messages and program state is also about *preserving information* about the failure at the point of throw. Loss of information is what you are battling here, since once you lose/throw away information it is a huge effort to reconstruct it later. Avoiding loss of information is worth keeping that in mind as you develop, so you avoid doing it. Example: the built in NullPointerException being the worst example of providing zero additional information about what was null, a problem if you have multiple chained method calls on a single line. Don't write code like the Java code that raises NullPointerException.
I'll step out now as you've merely descended into another mindless rant laced with insults, and more lies and falsehoods.
Please do.
If you can't see why the rise of the far right through politics in nations with some of the highest defence expenditure in the world and nuclear weapons fitted on global delivery systems (Britain, Russia, and France) is a bigger threat than a bunch of angry people living in abject poverty in nations like Saudi Arabia whose military is only a signature in the Whitehouse away from losing the funding it requires to survive turning the nation and it's leadership into the latest target of the arab spring then you really aren't capable of having this discussion.
These countries are powerful but *regional* players. As a European they loom large for you - but for most of the rest of the world they are insignificant. They don't matter a whit on the *global* stage because their power projection is limited, and they don't have the will to dominate the globe. What matters is who is most likely to reach out and affect ordinary people in the places they live and work, or when they travel. The relative insignificance of Britain, France and Russia is of the same order as China, which is the regional nuisance here (with its neighbours getting bullied by its imperialist agenda in the South China Sea, which is real, unlike your theoretical postulations).
Certainly a country taken over by the far right would be very bad. I don't think it is very likely in Britain or France. Yes, the right gets in but they usually become centralised slightly once in office. Plus, in order to implement your fears they need to eliminate their political opposition. It's just not going to happen in the way it did 80 years ago. In Russia, well they've always been dodgy and they are destroying any moderating opposition. However, the probability of this happening is still lower than other threats that are already in motion - and the US still has the power to cotain Russia (the US defensive missile program gives more options without having to resort to MAD, and the Russians know this which is a good restraining factor).
It's just a shame that you have become exactly what you claim to preach against - an extremist, and that what you claim to argue for, internet freedom, you don't actually want.
Utter codswallop! You keep projecting attributes on to me that are assumed and completely false (just like your complete ignorance of New Zealand, and then the clueless insulting of a country and its inhabitants you have little real idea about; at least I've been to Britain numerous times, have you ever been to NZ and seen how diverse and inclusive it is?). Unfortunately it appears your mode of debating is to continually project strawmen on to people, and then knock your projection down. It appears you still have not listened to the (progressive, not fascist!) references I keep talking about (and I keep talking about them because your strawmen would be destroyed if you did the research - and then we could progress the debate in a rational and informed manner).
I'm not an extremist at all, I simply follow the line of reasoning of esteemed progressive thinkers like Hitchens, Dawkins, Harris (and the slightly more rabid, but factually correct Condell). But please don't let me spoil your (dare I say, extreme) delusions about an imminent return of imperialistic fascism or your delight in characterising someone trying to get you to do some *basic research* as an extremist :)