skysight-inc/HackerNews huggingface dataset:
> Exceptions should almost never be caught.

That's exactly where the controversy lies.

The string conversion issue was brought up because I think it is an excellent case of 'programmer knows best', but the exception causes the whole dataset to be rejected, not just the one record out of 3.9 million that were fine. That's obviously sub-optimal. There has to be a better way to deal with that sort of thing, such as for instance an 'output' vector where data that couldn't be processed can be sent, or a series of warnings / errors attached to certain offsetts in your data. Then after running the conversion you can decide if you want to drop all of it (which is what happens now) and fix the input data, or discard those records (sometimes that is an option), or manually edit those and then run the import on those few records again.

Because exceptions are a mechanism you can then 'use' them for whatever you feel like. Just like you can use setjmp/longjmp in C for all kinds of creative stuff you can use exceptions to change the dynamic of your program. And this leads to some very difficult to trace code because exceptions break the normal flow.

Almost all exceptions in for instance the python mysql layer need to be handled by your application otherwise you will be exposing the user of your application (or website) to a runtime error and that is not good, not handling those is not really an option (unless you don't like your users much :) ).

So, in production grade software you'll find that almost all possible exceptions are indeed handled, and if possible as close as possible to the location of the error to make sure the fall-out of the problem is minimized.

Generally speaking, the higher up the handler the less information there is about the context of the exception, the smaller the chance you can handle it in a meaningful way.

This style of coding makes it not rare to see half the code to be about exception handling, the other half actual 'productive' code. Especially Java suffers from this very much.
Interestingly in the patent's cited prior art is this "Girocycle" (appears to be closest, other pa is handles and the like) - http://www.google.com/patents?id=xgw6AAAAEBAJ&printsec=a...

It's a flywheel gyro system, so it uses the speed of the vehicle and on breaking releases the flywheel to maintain gyro stability - that's the ground breaker ... in 1986, presumably that patent having expired in May 2006 explains the timing? (the startup being from April 2006?)
Sustainability is a nonsense if a comet impacts the earth.

You don't run a service on one machine; you use redundancy to reduce the chance of catastrophic failure.
Hazelcast - In-Memory Data Grid for Java
Programming languages shape the way programmers solve problems. To use your terms, when a compiler forces one to deal with a problem with spatial immediacy (i.e. checked exceptions), and the language uses spatial colocation to represent temporal colocation to a greater or lesser degree (as most imperative languages do), then the programmer is being encouraged, quite strongly, to solve the problem in similar space and by consequence in similar time.
Gladwell popularized the "10,000 hours rule", but he didn't invent it. It's originally from a paper by K. Anders Ericsson on "deliberate practice" [1]. It cites a ton of other research in the area and is definitely worth reading if you liked Outliers.

[1] http://projects.ict.usc.edu/itw/gel/EricssonDeliberatePracti...
As a professional Java programmer, with some experience in various strongly typed languages (MLs, Haskell), I really liked the idea of Checked Exceptions when I first heard about them (and even when I used them in small projects in school). In principle, it seems like a way to allow for stronger static analysis and allows the compiler to make stronger safety guarantees. It also forces programmers to deal with oddball cases - instead of just ignoring them like we are prone to do with magic return values (a la C) or unchecked exceptions.

The problem is it never works. There are two common strategies that I've encountered to deal with 90+% of checked exceptions:

-Most code just bubbles the exceptions up the top layer (i.e., the UI), which clutters up every method signature along the way. The UI then has a big handler that catches all exceptions, and just logs an error and shuts down the program. Even on the off chance that the top-level could do something more productive, the problem is that the stack has been unwound too far and it's too late to fix whatever the problem is.

-The other common approach is to wrap every checked exception inside a custom unchecked exception that is just thrown. This is my preferred solution (at least it doesn't clutter up every method signature), but I have to explicitly convert every checked exception into an unchecked one - which is just a bit of a hassle.

I give Sun some props for trying out on a limb with a really cool sounding idea. But I think most people have realized it doesn't work very well in practice ...
What specific regulations made the biggest difference?

The biggest factor I've read about is that Canada -- as a society and government -- never got on the "promote home ownership at all costs" bandwagon. There's no equivalent of Fannie and Freddie, and the traditional mortgage requirement of ~20% down remains. Thus Canada hasn't had the same sort of housing bubble, nor as many dubious mortgages, nor widespread mortgage securitization.
How to blink an LED over the net using python, and arduino.
When you are content to be simply yourself
and don't compare or compete,
everybody will respect you.

-- Lao Tzu
Mobile Gmail and async script loading
http://en.wikipedia.org/wiki/E-mail_letter

http://www.mailaletter.com/

http://www.netgram.com/

http://www.flydoc.com/

http://l-mail.com/

http://www.ezgram.com/

http://www.postful.com/

http://www.postalmethods.com/
Bre Pettis of MakerBot and NYC Resistor
For your string example, a callback would probably be the most flexible solution, but I still believe that not signalling corruption when it is found by library code is irresponsible. Batch processing code will have a loop; that's precisely where there should be an exception handler, one that can log that there were errors with this particular record, so that attention can be brought in later. If the data isn't too important, then sure, minor corruption can be ignored, but it would be a terrible default.

Taking your database interaction example, here are the kinds of situations I could see, and responses:

* Failure to connect; this is pretty fatal, unless there's home-spun failover support, it should not be handled at a low level

* Query syntax / API error: this is a programming error, should be logged and the current process (request, whatever) aborted

* Constraint failure: choosing whether to handle constraints on the database side, or on the app server side, or both sides, is an architectural decision with tradeoffs. Ideally constraints should be portable, so that they can be transported all the way to the UI, and checked at every stage along the way. These constraint failures might be signalled through exceptions, but that's a tactical choice, and may not be the best one. Generally, exceptions only signal for the first error, but usually there is more than one constraint, and multiple actionable failed constraints should be propagated to avoid wasting the end user's time (consider the simplistic compiler which halts on first error).

My point is that exceptions should generally either be things you can't reasonably handle, with a non-throwing "out" for situations where you do expect to be able to handle the problem. If you expect to be able to work around the issue, i.e. find a solution locally, low down in the stack, then you probably shouldn't be catching an exception in order to do so, unless that's impossible (like the race condition I mentioned earlier).
You make a very persuasive point, but I have reservation regarding the words "encourage" and "solve".

I would think the fact of the possibility of mapping exceptions (according to some abstraction order mirroring the layering of the overall system) calls for "acknowledge" instead of "solve".

And compilers can help with robustness of programs, but their influence on the robustness of programmers is not immediately evident. So perhaps "suggests" instead of "encourage" for a subset of programmers?
What you are saying is completely different from someone asking you "What college did you go to", and responding vaguely "Boston" when most people just say the name of the school.
The failure modes of software written in C versus memory safe languages, with particular attention to security and buffer overflows, persuades me very strongly that languages (and their implementations, i.e. compilers) do indeed influence the robustness of programmers. What is a programmer other than the programs he writes?
More information on the GCD FreeBSD port is here: http://lists.macosforge.org/pipermail/libdispatch-dev/2009-S...
Really? Walk through the curriculum starting around the 3rd grade onwards - It basically sets up a foundation for future learning in all disciplines. Reading, Writing, Arithmetic - I remember the precise instant (3rd grade) that I was introduced to the concept of a negative number. It blew my mind. And science classes theory in seventh and eights grade were awesome - if I hadn't been grinding I probably would have never learned about umbra's and penumbras, angle of reflection, etc... as well I did.

I think you get out of any experience (Sports, School, Start Ups) what you put into it. And I have to agree - the entire point of the article, that people who haven't been able to demonstrate "success" in school, do tend to be a bit more defensive than those who have. I don't know if this applies to other fields (Sports, Startups) - but it's certainly seen in schools with regards to academic achievement. (BTW, We can all agree to hate the valedectorian who not only graduated with a perfect 4.0 GPA, but also spent close to 30% of her final two years of high school traveling Europe, preparing for the winter olympics, and participating in the debate club)
This is a standard problem, not just in CA. Assuming you don't need CA qualification, which is something for your lawyer not your bank to figure out, give them a letter stating that you have no employees in the state and as such don't require CA qualification. That and some persistence should get you what you want.
Maybe it would be more useful to declare what types of exceptions method handles. Declaring what types of exceptions methods (throws|receives and not handles) should be optional. The way it is now is too much work and too little gain in typical setups.
"The thing is that seventeen rules of Xanadu, in themselves, aren't that much more complex than the WWW - The http protocol is not an uber simple thing."

I have to disagree. Requiring secure identification of a web server means that every web site must use an SSL certificate. Most likely, the way it was intended, it must also be an identity-verified SSL cert, i.e., "Verisign" et al, not just "some SSL cert I generated last night". Requiring secure identification of the user at all times is very onerous when propagated throughout the entire stack, as it would have had to have been. Now you have to be logged in to all sites, all the time, with some sort of universally-agreed-upon protocol which would run smack into the problem that not everybody's identification needs are the same. "Every user can store documents" means you are not allowed to browse the Xanadu without paying for hosting privileges. Backwards links complicates every CMS, ever, horrifically, and also has to manifest in the protocol. And I'm not even all the way through the list, the problems keep going, but I fear boring the reader.

If you look at what they really mean (remember, these are summaries), it is night and day. An elementary HTTP server can be bashed out in an hour, and it'll work with modern browers to at least some degree. In college, writing an HTTP proxy server was a 2 hour lab assignment in networking class, to give an example of another piece of the stack. AFAIK, nobody has ever produced a full Xanadu server, despite massive amounts of effort. This is not a coincidence; this is a reflection of the almost-impossible-to-overstate difference in complexity between the two ideas.
Downvoted obviously from a Stanford grad.
By "immediately", I meant as you write the code. Type the code, hit return, and you have an error. "Immediately" you have to decide add a try or change the method signature. I think this causes premature exception handling, just because the programmer wants to get moving along with the code. Checked/unchecked seems to mirror static/dynamic typing, but it doesnt. It's orthogonal. Exception handling is an application specific implementation strategy, but checked exceptions force a "religion" on you.
Unemployment rate for Americans aged 16-24 is now 52.2 percent
> My point is that exceptions should generally either be things you can't reasonably handle

That we completely agree on.

As for that race condition, I think that a situation like that could easily be avoided by having a single task be responsible for maintaining that data structure and to send it messages to update the state atomically.

That way you avoid the race completely.

Race conditions usually are a sign of multiple parties having access to a single resource where you'd be better served having one 'handler' process in charge of the data object that multiple parties want to access. It can then be the arbiter of who has access.

If the changes are a-synchronous then you could use a 'fire and forget' style queuing mechanism where the only thing that matters is that you know the message was received, the more tightly coupled example you gave could be handled reasonably elegant with a client-server model where the server will handle only client at a time for a particular resource.

Data objects not being 'alive' enough is the cause of many race conditions, by assigning a handler you achieve two things in one go, the first is an abstraction of interaction with the data object to a series of messages to a handler, the second the removal of race conditions and their 'normal' solutions (such as locks).
Almost selling is not selling.
IIRC that's what C++ does and I recently read that it's mostly ignored. Of course a compiler or IDE could detect what is caught and generate the javadoc equivalent. That would be useful.
> The string conversion issue was brought up because I think it is an excellent case of 'programmer knows best', but the exception causes the whole dataset to be rejected, not just the one record out of 3.9 million that were fine.

The programmer first has to know that he has to make decision what to do with partially wrong input and there is no better way to let him know than throwing exception in his face. Then he will know that there is configuration option that will let him to go around the problem one or other way.

Default option in case of any trouble should be exception bubbling up with information what can be done to avoid it.
PEP 389: argparse - new command line parsing module for python
I'm not trying to score rhetorical points here, but it seems like you're trying to change the subject after having one of your unconscious assumptions brought to your attention.

Everybody has them, and, er... by definition... nobody is aware of them. Most people try and forget all about them when they do become visible, but is that the ideal reaction?
Search isn't a business. It's just a technology they developed. If Google hadn't found their advertising business, they would have failed.

You don't want Google's search technology because it will make you money. You want it because it has brand value and lots and lots of users that you want to leverage to make money using some other business.

Walmart's business is selling merchandise. The fact that they have to be experts at building construction so they can make stores to sell merchandise is just as secondary as Google's search business.

Would you rather have Walmart or their real estate?
You forgot hotbot!
a() throws Exception;
b() throws Exception;
c() throws Exception;

eeeverbody() throws Exception;

There, I dealt with exception handling.
That looks amazing. I love the sale in the intro. "You own the most beautiful oceans, the most beautiful mountains" etc. A really interesting way to look at the national park system!
The race condition example applied to a pretty global "single resource": the file system; and came from the example in the main article. In situations where you have greater control over the resource, I agree that serialization / independence of operations, whether by transactions, queuing, single arbiter, etc., is better.
we have people in orbit for that right now
IMO almost all of the problems people have in practice with checked exceptions are from poor API design rather than an issue with checked exceptions themselves. The core Java APIs use checked exceptions for too many conditions which are not recoverable - causing a whole bunch of maintenance pain for no benefit. This is understandable considering that Java was the first mainstream language to really exercise the concept.

If used judiciously, I think checked exceptions do have benefits. There are classes of errors that are exceptional but also conceivably recoverable. The fact that they are exceptional means it is important to draw attention to them (they may otherwise be overlooked). The fact that they are recoverable justifies requiring calling code to make a choice - handle or propagate the error. Even in these cases, the code can get messy, but I see that as a fact of life: writing robust code isn't easy.
One of the things that's nice about Common Lisp style conditions is that they do not automatically force a stack unroll. You can, and people do, signal conditions like "I don't know what to do with this" that can be handled inline (say, with the coding table, replacing it with "?" although I personally loathe that "fix") and then the parser goes along its merry way. The same library can be used to say "WTF? this is in no way the data file I wrote out. Bail!".
This reminds me of how venture capitalists will sometimes ask founders about their TAM, or "total addressable market". The TAM is basically the amount of money you would make if every single eligible human being on Earth purchased/consumed your product.

I will never forget one night I was with a friend and he calculated his TAM to be something like 940 billion dollars. For his web startup.

After calculating this number, he said "Wow, if only 1%..."
I clicked the ad. I didn't buy the shirts, because last year was the year I grew out of buying t-shirts.
Heh that takes me back to my "Programming Languages" class, taught by Friedman, and using The Little LISPer as a textbook.
A VC (or anyone else) who cares more about the number than how you calculated it is a moron.
Yet-another-post-about-chinese-math: http://www.businesspundit.com/please-stop-with-your-chinese-...

Sigh. If only 1% of bloggers stopped re-hashing old ideas, then we'd have something actually good to read on HN.
If you have a one-on-one tutor I don't think I would be too worried about taking a long time to learn the language. It's much more effective just having someone to talk to, TPS or not.
Reminds me of Steve Blank's sayings on the customer and product development cycle. His mistake was he ramped up before properly understanding his customers (and how to best sell to them).
The reverse of this is vapourware, marketing without a product behind it.

Kudos to the guy for trying, but sometimes it is better to anticipate a less than stellar showing and to plan accordingly.

What will strike consumers fancy is a very difficult and sometimes impossible to answer question. Some stuff that you see and think can't possibly sell will make someone a millionaire, another has a great and well thought out product but nobody needs it.

Most products end somewhere in the middle. Even the largest companies still struggle with this, occasionally their 'focus groups' get it so wrong it isn't even funny.

If you're in the 'brick & mortar' side of things then you will have learned the hard way that too little inventory is just as lethal as too much, to hit that sweet spot is quite hard.

A buddy of mine trades goods that he buys in bulk at bankruptcy auctions, the diversity of the goods is huge, as is the pricing. Every time he bids on a lot he has to make a gut call on how fast he'll be able to turn that stuff over, if he misjudges several times in a row it can seriously hurt his business. He has one golden rule that came out of doing this for a while: It's better to have money in your pocket than stuff you bought that you can't sell.

So he errs well on the side of caution, is prepared to let others get away with 'great deals' simply because he builds in a level of cushioning that he needs to maintain his balance. If he can't get it at the right price, he's better off without it.

It's hard, even with hindsight to tell the musician from the example how he could have done better, I've had some contact with a 'name' artist that produces his own CDs, his method is to go for the long term relationship with his customers, including samples, mailing lists and so on.

By the time his CDs are pressed he knows exactly how many he will sell short term and how many will take up space for some time to come.

Selling music of an unknown artist through a newspaper ad seems to be a mismatch of medium, chances are that through a better medium he'd have been able to move much more of his inventory.
Considering how much people are still falling into this trap, it definitely needs to be rehashed more.
What kind of product do you want to work on that you would feel passionate about?
Grades are a sign of intelligence ?

This could simply be a student's willingness to parrot whatever answers or theory a teacher would like to hear. Ever notice that often when a student outdoes his teacher or his teacher's favorite 'pets' then he is down-graded ?

The world's best scientists, mathematicians, physicists have all experienced this especially when their thinking was about to improve on and/or replace the old theories that their professors used for large grant money.

Maybe there was a good reason that it was a crime in Socrates day for teachers to accept money from students.
Does financial incentive corrupt education outright ?

"Prestigious" schools also deny those that need tuition most when the whole point of attending is to gain something(knowledge etc.) that they do not already possess. These schools also pride themselves on cultural diversity but what about the classicism that defines their admissions ?
Why should a decent degree run a student into 100-200k of debt after graduation ? Less wealthy countries provide comparable and even better education for free. Why ?
http://goingtorain.com, I think.
You mention the quality of the candidate's questions. Do you find those questions are general or an indication that they did some research before coming to the interview and thus specific to your company and/or the technologies that you use?
That metric has long been flawed.
Showcase of Designs Optimized for iPhone
Notes on the Four Color Theorem (4CT)
Miracle Berry - makes sour taste sweet.
> Industry watchers have pointed out that the firm still has no way of making money.

is not currently making money != no way of making money