That's a great question. You start to need a concept of transactions and rollback in more places. Databases already have this. Journaling filesystems already do this to an extent. (Btrfs actually COWs, so you theoretically could roll back to an older version also.)

I'm not saying you can do this everywhere, but I think it's a strategy that can find a home many places.

Speaking of iOS: Are you saying that if the battery is low, the phone should shut off without warning, saving all data, or give a few warnings as the battery gets low? The no-error-alert paradigm is just stupid.

My car warns me when it detects a failure, and I think it's no failure of software designers if they also warn me when things are amiss. I'd hate it if my car just tried to "handle" low fuel, low oil pressure, low tire pressure, or what-have-you, as about the only thing it could do for any of those is just stop. iOS devices are in a similar circumstance with low battery.

Are you still of the opinion that there should never be an error alert unless it's the programmer admitting some sort of failure? "I failed to program an infinite capacity battery."

Make forking exceptionally cheap, and move to a checkpoint-and-commit paradigm. Fork just before the first open(), go acquire all your resources (open(), malloc(), etc.). Depending on whether all that succeeds or part of that fails, you know which thread to kill. Kill the thread that did the open, etc. if that path failed, otherwise kill the thread that's waiting at the last checkpoint.

If that sounds at all familiar, it should. Most modern CPUs already do this in hardware. It's called speculative execution, and they do one of these forks at nearly every branch.

In this example, what if the failing function just returned NaN, and you let the NaNs propagate? I guess in some cases you care which of factorial(), zeta() or geommean() failed, but more often you care whether the expression as a whole failed or not.

Hmmm... so if I ask a program to read a file that doesn't exist, should it just create an empty document of that name? Possibly the right answer for a word processor, but quite probably the wrong answer when specifying an attachment to an email.

I think that statement needs to be clarified: An internal error alert pop-up that could happen without a hardware failure is an admission of failure on the part of the programmer, no doubt. But, if the user truly is in error, there's nothing to admit on the programmer's part when they tell the user they're wrong. The program still has to check the user, though.

...write code without error.

How to I find users that won't give it incorrect or inconsistent input, or hardware that won't fail unexpectedly? I don't program the users, and I've yet to find 100% reliable hardware that never wears out.

"Never test for an error condition you don't know how to handle." -- Steinbach's Guideline for Systems Programmers.

Ah, that's a bit different. It's advice as to what level you should place your error checking. For example, if you do "fd = open( ... )", you probably should at least check the file descriptor, since you know you can't proceed without it. But, you don't know how to fix it, so pass it up. But, if a subsequent call to "write( )" fails, most of the time you don't actually care. (In the event you do care, because it's critical that your write succeed, then check. But, I argue in most cases, it's OK to let the write silently fail; folks will notice their disk got full in other ways.)

Wow, that sounds like the programming equivalent of bumper bowling.

I happen to agree that exceptions should be left to exceptional events—something entirely outside the scope of the algorithm—and not something that seems well within the purview of the task at hand. For example, when validating data sets, which is something it sounds like your code does, detecting and handling an invalid datum sounds like the code's raison d'etre. An exception here would be ridiculous.

Another example might be a parser of some sort (for example, in the compiler itself). If it detects an error in the input, that's not an exception. It's a well defined state transition in the parser. Exception handling is not error handling in the general sense. It's only for errors for which the right course of action isn't even knowable except perhaps a couple levels up, and is unlikely to happen much in practice.

For example, if you have data structures that automatically resize to fit whatever your program needs, and you hit an OOM situation, what then? There's likely to be no good way forward. You want to unwind far enough that you can leave things in as consistent a state as possible, and otherwise probably just crash with a hopefully-useful error message. Depending on the nature of the program, "crash" could mean widely different things here. If it's a command-line program or a restartable system service, "error message and exit" is probably the best thing. If it's a GUI environment, if you can close the document or whatever triggered the blow-up and free the resources, that's probably a better idea.

Drifting topics here...

I'm fortunate that most of the programming I have to do is best served by Perl's "die", "croak" and "carp" functions. Usually, whatever error my scripts encounter is best handled outside the script, because the error is either bad input, or a bug in the code. Neither of those can really be handled within the script itself. So, we pop out an error message and a stack trace and say "here, you fix it."

Before you say "you're putting an undue burden on your users," most of this code is developed for ourselves to use. I work with a chip design team, and we manufacture and eat our own dog food. Just as the scaffolding around a skyscraper-under-construction doesn't need to be ADA compliant ("What, no wheelchair ramp up here?"), our scripts for internal use don't need quite as much polish as something we'd ship as a product. :-)

That said, I do also work on code that I intend other less-technical people to use. It takes considerably more work to make that code bulletproof and friendly. I'd say more work goes into polish than into the core algorithms.

The defining aspect is the medium the craft is flying through. The solar wind has dropped from supersonic to nil, and the Sun's magnetic field is about to be superseded by the overall galactic magnetic field. I'd say that's a pretty good definition of transitioning from the solar system's medium to the interstellar medium, since the space the craft is floating through has changed qualitatively.

I guess it's a bit like the difference between the boundary of the Earth's atmosphere, and the orbit of the Moon. The Moon is gravitationally bound to the Earth, but the Earth's atmosphere ends well before you get to the Moon. Where do you say the boundary of space is as you leave the Earth?

Comparing to cars isn't quite fair. For one thing, Voyager doesn't have to deal with traffic, accelerating, decelerating, etc. Its commute is more like "Hang a left with gravity assist at Jupiter and cruise for the next several years." It doesn't even have to gas up.

It doesn't have to deal with pot holes, school zones, daredevil drivers, stop-n-go traffic, or heck, stopping and going in any sense. It's been slingshotted into space and can make subtle adjustments to its course or pick up the occasional planetary gravity-assist, and that's about it. If it were to totally croak today, it'd still keep flying into the interstellar medium. We just wouldn't be able to hear about it if the telemetry gear croaked.

And before you go on to praise the unprecedented electronics, realize there's plenty of people still developing home brew games for Intellivisions and Ataris, and they're almost as old... All those old consumer electronics gizmos still function, and were produced at a fraction of the cost. The only reason newer electronics haven't run for as long is, well, not enough time has passed for them to have run that long.

You can get anything you want, at Alice's Asteroid
You can get anything you want,
At Alice's As-ter-oid
Float right in, orbit's round the back
Half an AU from the railroad track
You can get anything you want, at Alice's Asteroid.

You could design a single-use code that isn't a random pad, such as assigning meanings to sequences of letters, in essence making a set of "words" for that mission. For example, "CQ" might mean "soldiers", "TQ" might mean tanks, etc. Notice in the ciphertext, the triad JRZ is repeated twice and the first and last 5 characters are the same.

That said, spot checking a few letters, it appears the distribution is pretty flat, suggesting an OTP. If you strike the last 5 letters (assume they're a repeat of the first 5, a sort of framing protocol), you'd expect each letter of the alphabet to get used around 5 times, and that's about what I see.

One Time Pads are indeed impossible to crack, if the pad is indeed used only one time, and is indeed fully random. That's because it makes any message that's the same length as or shorter than the ciphertext equally likely.

If I sent you the ciphertext PDXS, how would you know if it decoded to "EAST", "WEST", or any other four letter word?