This is a design/requirements problem to me, not a language one. You can handle no internet connection in just about every language, but you probably won't if you don't say something about needing to do that, and plan how to store/access the data in that failed state.
If the stakes were higher (say, brain surgery to get some study results), you'd want even more planning around storage/access so that your disk doesn't die and the server is unreachable at the same time and lose the only copy. Letting a developer come up with this on their own is a footgun with an incredibly sensitive trigger.
The other reason it's design/requirements is so everyone knows and it's not just Tim the developer coming up with his own idea and not really detailing it to anyone, and then Tim gets hit by a bus and someone has to go figure out what he did (or more likely, fired because they thought AI could do all of this for them).
I think that's a very important point, but I wouldn't call `or die()` an affordance. A common idiom, perhaps.
A common affordance that invites mistakes is something like `file_exists(path)` (because it often introduces hard-to-debug race conditions), or `db.query(string)` (because it invites string interpolation and SQL injection).
It's ironic how PHP's philosophy of "ignore errors and keep chugging along" has lead to developers habitually adding "or die()" (crash on error) to everything, even in this instance where chugging along at any cost would have been the exactly right behavior
I wonder if they would have spent more thoughts on error handling in a language that defaults to crashing on error (e.g. Java's exceptions)
Forcing developers to handle errors properly is a difficult thing to do in any language. Their solution to use JavaScript kind of surprised me: yes, `exit()` is not something common in JS, but if the code to send email threw an exception (instead of returning a boolean, which seems to be the case here) it would probably exit as well, but in an implicit manner, worse than `or die`.
However, Java has checked Exceptions which would force you to handle the possibility explicitly or the code would not compile, but the Java experience shows that almost always, people will just do:
Or even just log the Exception (Which would actually be the right thing to do in the case of the study!).
With Go's multiple return values to represent errors, they are also known to be too easy to "forget" to even look at the error value.
With Rust's approach, which is using sum types to represent either success or error (with the `Result` type), it is impossible to forget to check, like Java checked Exceptions... but just like in Java, arguably even easier, you can just sort of ignore it by calling `unwrap()`, which is fairly common to do even in production-level Rust code (it's not always wrong, some very prominent people in the Rust community have made that point very clearly... but in many cases that's done out of laziness rather than thought), and is essentially equivalent to PHP `or die` because it will panic if the result was an error.
Linters like SpotBugs tend to complain about that. But it’s also a matter of naming. If RuntimeException was instead called something like ProgramBug, people might be more reluctant.
In the end, it’s an issue of education. People need to be aware of the possible consequences, and have to be taught how to properly handle such cases. There is no way to automate error handling without the developer having to think about it, because the right thing to do is context-dependent. Checked exceptions at least make the developer aware of failure modes to consider.
In this case, I think the actual API we used would take a callback for success, and a callback for errors. I just used JS an example for how unnatural it would be to call something that exits the entire script early.
I have a big problem with promises + exceptions generally in JavaScript - much preferring union types to represent errors instead of allowing things to go unchecked. But I left that out as it was kind of a side-note from the point of affordance.
You can't force developers to handle errors correctly (outside code review). But maybe you can change what their first thought or habitual action is. In go or rust for example the habitual behavior is to throw the error upwards. In go with a three-line if statement, in rust with a simple `?`. In php the habitual behavior is to crash on error. As you point out that's not that different.
Maybe a better example of the opposite would be python, with its unchecked exceptions. One of my first thoughts in python error handling is "here I don't want exceptions to propagate, let's throw in a lazy `try ... except print(...); sleep(1)`.
But I'm not sure I actually do that more than e.g. in rust, simply because I write them in so different environments (my python code just has to run and produce correct results, my rust code is rolled out to customers and has to pass code review)
I often find myself wishing for a Checked Exceptions, I think things would have played out differently if there was more syntactic sugar.
Like if one could easily specify that within a certain scope (method or try-block), any of a list of exception classes (checked or unchecked) will become automatically wrapped into a target checked exception class as the chained "cause."
So you could set a policy that EngineBrokenException=or OutOfFuelException bubbling up will become FleetVehicleInoperableException.
I understand what you're saying about the potential annoyance or dissatisfaction with Java checked exceptions being effectively cast to Runtime ones. As a language choice, it made a signal by differentiating checked versus unchecked and at least gave user the opportunity to benefit from a choice witha nudge in the right direction. You always have to have the escape hatch, but making it less "affordable" to the user, they tend to do the right thing more often which sounds like a perfect win given the trade-offs.
This is why a lot of Go users like its error handling as it is. It forces you to explicitly think about how you want to handle the error.
Of course, it can't prevent people from pasting an error handler everywhere instead of thinking about it, which I think are the same people who hate Go's error handling
I think they are actually pretty different in approach. rust sprinkle ”?” everywhere and wants to avoid dealing with the error, and golang is more explicit and robust handling. sure, most is similar if it is just ”if err return err” but I have definitely seen more ”extreme” and correct error handling in golang, whereas in rust the convenience of just bubbling it up wins. I still prefer rust, but I am not sure the comparison is as close as people claim
> rust sprinkle ”?” everywhere and wants to avoid dealing with the error
You certainly must handle the error if you want your computation to continue.
> golang is more explicit
Not sure how golang is more explicit. In functor-based style, an error-prone computation stops if it yields an error and that error isn't handled explicitly. That makes sure that any successful computation is based on expected behaviour from beginning to end.
> and robust
Likewise, that's a claim based on nothing. Forcing developers to write a little snippet of code everywhere lest their code has a bug does not make code more robust.
> but I have definitely seen more ”extreme” and correct error handling in golang, whereas in rust the convenience of just bubbling it up wins.
You also have the option to match a result for lower-level error handling in rust.
Claiming that "convenience" makes rustaceans not use that option is like claiming that gophers don't check the error content because it's faster to panic.
Sprinkling "?" everywhere and the properties you mentioned are not really a different approach by the language but by the (some) users.
I am not even sure if Rust is that more convenient in this regard generally.
To actually be able to use a ?, you have to actually define a conversion for the error types (which again you define yourself) or explicitly opt into a solution like anyhow, which would allow to use them almost blindly.
In Go, you can just blindly put your boilerplate (potentially using IDE shortcuts/autocomplete as some suggested to me or told me about).
> whereas in rust the convenience of just bubbling it up wins
Not necessarily, I have seen so many ways of error handling at this point, and what is best probably may depend on the individual situation.
In my personal experience, neither using anyhow nor my current default approach (custom error struct and `map_err(Error::EnumVariant)?` have prevented me from acknowledging that a potential error and thinking about if I should handle it in the current function or bubble up, although I agree that the perceived cost of handling an error may be increased, because you add comparatively more code in Rust.
Further, I feel like what Rust does is already the upper limit of boiler plate I can tolerate, although I am not sure there is a better way of this type of error handling.
Technically it doesn't because you can just ignore the error return and keep going anyway, its only a lint failure not to do something with a returned error. The language has a culture of dealing with the error straight away but the language doesn't enforce it.
In Java with checked exception you have no choice, you either try/catch it or you throw(s) it and are forced to handle it or its a compile error. Java does this aspect better, error handling features are relatively weak in Go but people have utilised the multiple returns well to make the best of it.
> In Java with checked exception you have no choice, you either try/catch it or you throw(s) it and are forced to handle it or its a compile error. Java does this aspect better
You don't have to give any consideration to that if you don't want to; you can always just catch the exception and rethrow it as a RuntimeException.
> If you don't make it easy to do the right thing and awkward to do the wrong thing, people with good intentions will do the wrong thing.
This is so important, but just isn’t heeded.
I work with some smart people, but they tend to defend choices by saying “It’s pretty straightforward” and “This is the way we’ve historically done this”.
I’ve gotten to the point where I don’t feel that I have the energy to try to debate, because it’s just like beating a ball against a brick wall. I used to rationalize it as “This will be a learning experience for them”, but no, they haven’t learned.
The way I put this practice into place involves accepting that people will just do whatever they find easiest, regardless of whether it's technically the right thing to do. I account for that when I'm designing APIs, languages ([Derw](https://www.derw-lang.com/)), frameworks, or tooling. If I make the correct thing the obvious or easiest thing to do, less people will do the incorrect thing. They will still do incorrect things, it's human nature. But they'll do it less frequently.
We actually did test. We didn't test in the exact same conditions or environment (i.e with no internet access), as we didn't find out about the no-internet restriction until the last minute. That is covered in this paragraph:
> While this bug was a costly mistake, we learned from it. Whenever we would deploy code-last minute, we'd try to test it more rigorously. If we were running a study without internet access, we'd make sure to test in the same environment. We hadn't accounted for the environment change, partially due to the short notice for the locked-down machine, but also just because we didn't test with the exact same restrictions.
For people who don't know how PHP works but do know Node, the Node example is really not at all similar. The result is similar but far worse; in PHP die() only makes that request die; in Node, it just exits the entire node server which could be doing other stuff. process.exit() is probably never a good thing while we see die() used, still, for 'security'. Not saying it's a great idea, but it's better than not having it in those cases; for instance;
if (!$user->active) {
<p>Fob off!</p>
die()
}
<p>Passcode to the world: <?php echo $world->pasccode; ?></p>
We encounter many cases where people forget these and so information gets accessed that should not be. Of course, this is just a unhandled cases is evil and they are:
if ($user->active) {
<p>Passcode to the world: <?php echo $world->pasccode; ?></p>
} else {
<p>Fob off!</p>
}
but in the wild (at many banks :), we encounter very many of the first case and often without the 'die' so a security issue. Our analysis tools catch all IF cases that don't handle all cases (which we see as an anti pattern, just like it's forced on a switch); alerting that this if has no else for the rest of the program to run makes people think and actually change their code. I rather see;
if ($user->blah) {
setSomething($user);
} else {
info("user not bla, not setting something");
}
# the rest
than what happens in 99% of code;
if ($user->blah) {
setSomething($user);
}
# the rest
because the next maintainer might add something to the setSomething that will make the # the rest sensitive, save, commit, deploy and we notice it when it hits the news of 64m records stolen or whatever. In the first case, it alerts the maintainer etc to the fact there is more and they have to think about it. There are better ways to handle it of course, but I'm just saying what we see in the wild a lot and we are only hired to fix the immediate issues, not long term, so long term refactoring is never a part. We do advice different patterns but no-one ever listens; our clients are mostly repeat clients from the past 3 decades.
Indeed - I have an extended equivalent from CGI-bin that I'm including in the full story in the book, since running things as a script vs as a program has different implications for killing the running process. The patterns you mention here tend to be my preferred way of working - exhaustiveness checking of branches. In modern TypeScript, I enforce that via union-type error handling rather than using exceptions (which are a nightmare when it comes to affordance imo). I'm generally a functional programmer rather than an imperative programmer. But the case mentioned in the blog post was about 12 years ago now, so it didn't have the same options as we currently have.
joe duffy made a really good write up distinguishing kinds of errors and how the programming language should have differnt methods for dealing with them: http://joeduffyblog.com/2016/02/07/the-error-model/
This is a design/requirements problem to me, not a language one. You can handle no internet connection in just about every language, but you probably won't if you don't say something about needing to do that, and plan how to store/access the data in that failed state.
If the stakes were higher (say, brain surgery to get some study results), you'd want even more planning around storage/access so that your disk doesn't die and the server is unreachable at the same time and lose the only copy. Letting a developer come up with this on their own is a footgun with an incredibly sensitive trigger.
The other reason it's design/requirements is so everyone knows and it's not just Tim the developer coming up with his own idea and not really detailing it to anyone, and then Tim gets hit by a bus and someone has to go figure out what he did (or more likely, fired because they thought AI could do all of this for them).
I think that's a very important point, but I wouldn't call `or die()` an affordance. A common idiom, perhaps.
A common affordance that invites mistakes is something like `file_exists(path)` (because it often introduces hard-to-debug race conditions), or `db.query(string)` (because it invites string interpolation and SQL injection).
It's ironic how PHP's philosophy of "ignore errors and keep chugging along" has lead to developers habitually adding "or die()" (crash on error) to everything, even in this instance where chugging along at any cost would have been the exactly right behavior
I wonder if they would have spent more thoughts on error handling in a language that defaults to crashing on error (e.g. Java's exceptions)
Forcing developers to handle errors properly is a difficult thing to do in any language. Their solution to use JavaScript kind of surprised me: yes, `exit()` is not something common in JS, but if the code to send email threw an exception (instead of returning a boolean, which seems to be the case here) it would probably exit as well, but in an implicit manner, worse than `or die`.
However, Java has checked Exceptions which would force you to handle the possibility explicitly or the code would not compile, but the Java experience shows that almost always, people will just do:
Or even just log the Exception (Which would actually be the right thing to do in the case of the study!).With Go's multiple return values to represent errors, they are also known to be too easy to "forget" to even look at the error value.
With Rust's approach, which is using sum types to represent either success or error (with the `Result` type), it is impossible to forget to check, like Java checked Exceptions... but just like in Java, arguably even easier, you can just sort of ignore it by calling `unwrap()`, which is fairly common to do even in production-level Rust code (it's not always wrong, some very prominent people in the Rust community have made that point very clearly... but in many cases that's done out of laziness rather than thought), and is essentially equivalent to PHP `or die` because it will panic if the result was an error.
In the end, it’s an issue of education. People need to be aware of the possible consequences, and have to be taught how to properly handle such cases. There is no way to automate error handling without the developer having to think about it, because the right thing to do is context-dependent. Checked exceptions at least make the developer aware of failure modes to consider.
Author here!
In this case, I think the actual API we used would take a callback for success, and a callback for errors. I just used JS an example for how unnatural it would be to call something that exits the entire script early.
I have a big problem with promises + exceptions generally in JavaScript - much preferring union types to represent errors instead of allowing things to go unchecked. But I left that out as it was kind of a side-note from the point of affordance.
You can't force developers to handle errors correctly (outside code review). But maybe you can change what their first thought or habitual action is. In go or rust for example the habitual behavior is to throw the error upwards. In go with a three-line if statement, in rust with a simple `?`. In php the habitual behavior is to crash on error. As you point out that's not that different.
Maybe a better example of the opposite would be python, with its unchecked exceptions. One of my first thoughts in python error handling is "here I don't want exceptions to propagate, let's throw in a lazy `try ... except print(...); sleep(1)`.
But I'm not sure I actually do that more than e.g. in rust, simply because I write them in so different environments (my python code just has to run and produce correct results, my rust code is rolled out to customers and has to pass code review)
I often find myself wishing for a Checked Exceptions, I think things would have played out differently if there was more syntactic sugar.
Like if one could easily specify that within a certain scope (method or try-block), any of a list of exception classes (checked or unchecked) will become automatically wrapped into a target checked exception class as the chained "cause."
So you could set a policy that EngineBrokenException=or OutOfFuelException bubbling up will become FleetVehicleInoperableException.
I understand what you're saying about the potential annoyance or dissatisfaction with Java checked exceptions being effectively cast to Runtime ones. As a language choice, it made a signal by differentiating checked versus unchecked and at least gave user the opportunity to benefit from a choice witha nudge in the right direction. You always have to have the escape hatch, but making it less "affordable" to the user, they tend to do the right thing more often which sounds like a perfect win given the trade-offs.
This is why a lot of Go users like its error handling as it is. It forces you to explicitly think about how you want to handle the error.
Of course, it can't prevent people from pasting an error handler everywhere instead of thinking about it, which I think are the same people who hate Go's error handling
I "hate" GOs error handling because of repetitive and verbose boiler plate when it comes to error handling.
Rust has almost the same error handling concept, but with way less boilerplate.
And Rust actually syntactically forces to handle the error case, because you can't just access the return value when there are potential errors
I think they are actually pretty different in approach. rust sprinkle ”?” everywhere and wants to avoid dealing with the error, and golang is more explicit and robust handling. sure, most is similar if it is just ”if err return err” but I have definitely seen more ”extreme” and correct error handling in golang, whereas in rust the convenience of just bubbling it up wins. I still prefer rust, but I am not sure the comparison is as close as people claim
> rust sprinkle ”?” everywhere and wants to avoid dealing with the error
You certainly must handle the error if you want your computation to continue.
> golang is more explicit
Not sure how golang is more explicit. In functor-based style, an error-prone computation stops if it yields an error and that error isn't handled explicitly. That makes sure that any successful computation is based on expected behaviour from beginning to end.
> and robust
Likewise, that's a claim based on nothing. Forcing developers to write a little snippet of code everywhere lest their code has a bug does not make code more robust.
> but I have definitely seen more ”extreme” and correct error handling in golang, whereas in rust the convenience of just bubbling it up wins.
You also have the option to match a result for lower-level error handling in rust.
Claiming that "convenience" makes rustaceans not use that option is like claiming that gophers don't check the error content because it's faster to panic.
Sprinkling "?" everywhere and the properties you mentioned are not really a different approach by the language but by the (some) users.
I am not even sure if Rust is that more convenient in this regard generally. To actually be able to use a ?, you have to actually define a conversion for the error types (which again you define yourself) or explicitly opt into a solution like anyhow, which would allow to use them almost blindly.
In Go, you can just blindly put your boilerplate (potentially using IDE shortcuts/autocomplete as some suggested to me or told me about).
> whereas in rust the convenience of just bubbling it up wins
Not necessarily, I have seen so many ways of error handling at this point, and what is best probably may depend on the individual situation.
In my personal experience, neither using anyhow nor my current default approach (custom error struct and `map_err(Error::EnumVariant)?` have prevented me from acknowledging that a potential error and thinking about if I should handle it in the current function or bubble up, although I agree that the perceived cost of handling an error may be increased, because you add comparatively more code in Rust.
Further, I feel like what Rust does is already the upper limit of boiler plate I can tolerate, although I am not sure there is a better way of this type of error handling.
Technically it doesn't because you can just ignore the error return and keep going anyway, its only a lint failure not to do something with a returned error. The language has a culture of dealing with the error straight away but the language doesn't enforce it.
In Java with checked exception you have no choice, you either try/catch it or you throw(s) it and are forced to handle it or its a compile error. Java does this aspect better, error handling features are relatively weak in Go but people have utilised the multiple returns well to make the best of it.
> In Java with checked exception you have no choice, you either try/catch it or you throw(s) it and are forced to handle it or its a compile error. Java does this aspect better
You don't have to give any consideration to that if you don't want to; you can always just catch the exception and rethrow it as a RuntimeException.
> If you don't make it easy to do the right thing and awkward to do the wrong thing, people with good intentions will do the wrong thing.
This is so important, but just isn’t heeded.
I work with some smart people, but they tend to defend choices by saying “It’s pretty straightforward” and “This is the way we’ve historically done this”.
I’ve gotten to the point where I don’t feel that I have the energy to try to debate, because it’s just like beating a ball against a brick wall. I used to rationalize it as “This will be a learning experience for them”, but no, they haven’t learned.
Author here!
The way I put this practice into place involves accepting that people will just do whatever they find easiest, regardless of whether it's technically the right thing to do. I account for that when I'm designing APIs, languages ([Derw](https://www.derw-lang.com/)), frameworks, or tooling. If I make the correct thing the obvious or easiest thing to do, less people will do the incorrect thing. They will still do incorrect things, it's human nature. But they'll do it less frequently.
Invite mistakes, yes. But they didn’t test at all, even once, or they would have seen it fail.
We actually did test. We didn't test in the exact same conditions or environment (i.e with no internet access), as we didn't find out about the no-internet restriction until the last minute. That is covered in this paragraph:
> While this bug was a costly mistake, we learned from it. Whenever we would deploy code-last minute, we'd try to test it more rigorously. If we were running a study without internet access, we'd make sure to test in the same environment. We hadn't accounted for the environment change, partially due to the short notice for the locked-down machine, but also just because we didn't test with the exact same restrictions.
For people who don't know how PHP works but do know Node, the Node example is really not at all similar. The result is similar but far worse; in PHP die() only makes that request die; in Node, it just exits the entire node server which could be doing other stuff. process.exit() is probably never a good thing while we see die() used, still, for 'security'. Not saying it's a great idea, but it's better than not having it in those cases; for instance;
We encounter many cases where people forget these and so information gets accessed that should not be. Of course, this is just a unhandled cases is evil and they are: but in the wild (at many banks :), we encounter very many of the first case and often without the 'die' so a security issue. Our analysis tools catch all IF cases that don't handle all cases (which we see as an anti pattern, just like it's forced on a switch); alerting that this if has no else for the rest of the program to run makes people think and actually change their code. I rather see; than what happens in 99% of code; because the next maintainer might add something to the setSomething that will make the # the rest sensitive, save, commit, deploy and we notice it when it hits the news of 64m records stolen or whatever. In the first case, it alerts the maintainer etc to the fact there is more and they have to think about it. There are better ways to handle it of course, but I'm just saying what we see in the wild a lot and we are only hired to fix the immediate issues, not long term, so long term refactoring is never a part. We do advice different patterns but no-one ever listens; our clients are mostly repeat clients from the past 3 decades.Author here!
Indeed - I have an extended equivalent from CGI-bin that I'm including in the full story in the book, since running things as a script vs as a program has different implications for killing the running process. The patterns you mention here tend to be my preferred way of working - exhaustiveness checking of branches. In modern TypeScript, I enforce that via union-type error handling rather than using exceptions (which are a nightmare when it comes to affordance imo). I'm generally a functional programmer rather than an imperative programmer. But the case mentioned in the blog post was about 12 years ago now, so it didn't have the same options as we currently have.
joe duffy made a really good write up distinguishing kinds of errors and how the programming language should have differnt methods for dealing with them: http://joeduffyblog.com/2016/02/07/the-error-model/
This looks very similar to the pit of success concept: https://blog.codinghorror.com/falling-into-the-pit-of-succes...