People keep saying this and I struggle to understand how this represents good design. In any language I can always just eat the error and keep going, or eat the error and restart.
That doesn't fix the error, and it doesn't imply the program will work correctly.
> In any language I can always just eat the error and keep going, or eat the error and restart.
Defer to pmarrek on what they meant, but to me it's an issue of practical programming.
In a choice between "I will tell you what to do about errors" vs "I will assume you only crash and restart on any error", I've found the later to be far more efficient.
The former generally leads to a rat's nest of never ending error specialization as unexpected or rare stuff bubbles up in UAT or down the road in prod.
Which isn't to say there's a right answer. There's always going to be particular situations where of course you should use one or the other.
But on the whole, as a philosophical default, fail-and-recycle-on-all-errors is a helluva lot easier to spec, code, test, and maintain for me.
That's an interesting discussion, and one that will still keep happening.
At a given point, you can handle errors, but there's nothing you can do about them
It's good when languages (and developers) realize there are errors you should handle but there are errors you "shouldn't" because there's nothing you can do but bail out.
If a thing can’t be null/nothing and there is nothing you can do it’s usually best to tear the world down. Otherwise in the best case you have a button that does nothing but in the worst case something bad happens. In the normal case the crash just moves. “Catching” programmer errors because a program that limps along looks better than one that crashes is a design decision I never understood.
Another way of putting it would be that languages should be designed so that there aren't gaping holes waiting for people to fall in. They should rather tend towards a "pit of success" - the easiest way to do things should be the correct way.
Error code results make it really easy to ignore errors. That's not a good thing.
Its problem is not that it exists, but that it’s a separate statement. In most languages, if you write try, you have to write catch or finally for your program to even start running.
If you write on error resume next, you should revert that soon, but the language doesn’t prevent you from forgetting to do that. Neither, AFAIK, do typical editors. A good editor, IMO, would indent code inside a “on error resume next”, but I haven’t seen such editors.
It does help that its scope ends at function/procedure return (I think), but of course, that means seemingly benign refactoring can change program behavior.
It isn’t too bad when you write new code, but once you start maintaining a larger program, it can bite you.
Haven't we realized yet that programs do not have a single flow of execution? each program has a few correct paths, and a few paths resulting from error.
Our languages so far pretend there is one correct path, and that the error paths are almost non-existence, or a nuesance at best.
In my opinion, what languages should do is the following, when an error happens: the program stops with an error report. There shouldn't be any errors caught ever. A faulty program should not be restarted; it should be fixed.
Doesn't it depend on the product in question? In some cases, you want to fail fast and loud. In others, you want to recover at all costs. Sometimes a single calculation going 1/0 means the whole program is failing. Sometimes it's a completely ignorable, minor error, not even worth checking for.
Can we please not have a "default" way of handling errors? None fit all.
Rebooting a program and losing state is always worse than error messages taking a bit longer to understand at first.
Not sure if it's _always_ worse. I've worked in imperative & functional languages, and the quality of error messages is key to solving bugs and understanding a sufficiently complex system, regardless of what language it's coded in.
I'm not exactly sure why that is either, but I do think most developers are appealed by the idea that a computer program is a closed system and thus any error that happens is a fluke, unexpected, and should be treated as catastrophic, when that is simply not true. Programs take input from the parent reality, asynchronously, and therefore aren't just subject to cosmic rays flipping bits in the hardware. Personally, I like to handle the possible errors intelligently, but many developers, especially web developers, love to just have any error result in an error page. Even worse, they sprinkle `try { ... } catch (err) { // do nothing }` all over the place, and that results in problems that are hard to track down or detect early.
"You might miss a lot of meaningful errors and get corrupted data, but at least the system keeps running, and that's the most you can hope for if your programmers are as crappy and lazy as the article describes."
What? If I'm working with crappy programmers I don't want the system to keep going and corrupting data -- in the vast majority of cases, that's the worst possible result. Taking down the system with an nice error message and stack trace is a much much better. Crappy programmers, in the presence of checked exceptions, will handle exceptions with empty catch clauses (to prevent breaking anything) and there will be no way to find that error when it happens.
I don't think so. You can choose to ignore the error (I know it's bad practice), but it's allowed. And sometimes you don't know what to do with the error
> What kind of utopian programming job do you have that you don't have to think about errors?
My job primarily requires thinking about errors. It is why I wish for Go-style errors in the languages I use.
But on rare occasions I write things like batch scripts, automations, etc. in which failure means addressing the issue in realtime and trying again. There you don't care much about errors other than ensuring that the world stops when an error occurs to allow you to fix the problem before continuing.
While contrived, if you run into a "client A attempted to purchase item B which is limited to client C" error in this space you're probably going to have to phone them up and tell them that you can't process the transaction, apologize for the mistake, remove record of their purchase, and then once complete run the script again. The program crashing with an error message is sufficient here.
"A great big codesplosion spraying you with a several hundred lines of stack trace and a "Your program has encountered an error an needs to close" is not "sensible behaviour"."
Yes it is, if it's a program in development where I haven't yet decided what behavior an error condition should produce.
You guys don't seem to understand I don't necessarily want to decide how to handle all errors now, not that I never want to have to think about how to handle them.
I've seen a lot of new developers shocked by this approach, which surprises me a little. They seem to think that it's up to the application to handle all errors, even those of the programmer(s). This, of course, is unreasonable since it would essentially require knowing all the bugs in advance. :-)
That doesn't fix the error, and it doesn't imply the program will work correctly.
reply