Hacker News Reader

Comment by arcticbull | Hacker News Reader

I agree and disagree. What the author says is true, if a thoroughly irrelevant part of your program (let's say a drawing routine for UI somewhere) hits an overflow and crashes your app in the middle of taking a payment, or in the middle of surgery -- while that much more critical element continued to work perfectly -- that's not ideal.

Not all parts of your app make sense to fail-fast. By enforcing this behavior even on peripheral parts of your app, you're taking away the decision making ability about what's important and what isn't from the system designer.

I understand that position, though I still think on the whole explicitness is right. Being able to explicitly disable the check when you know what you want is the right balance, whether it's &+ in Swift or (better, imo) .wrapping_add() in Rust.

View on HN

Displaying corrupt data in the UI can be just as bad as saving it to disk, if the user actually reads and uses the data you display (and if not, why are you displaying it?).

And since the UI almost certainly shares data with the rest of the program, bugs in the UI can corrupt the underlying data.

Separation of concerns is great, but if you really want different parts of your system to have different reliability constraints, then you need to truly separate them, for example by running them in different processes. Running them in the same process but having some of the code be more lax about state because it's less important is just begging for horrible bugs.

> Separation of concerns is great, but if you really want different parts of your system to have different reliability constraints, then you need to truly separate them, for example by running them in different processes. Running them in the same process but having some of the code be more lax about state because it's less important is just begging for horrible bugs.

Indeed, and you might even want to run them on entirely different and independent systems (connected by some type of network/bus) depending on exactly what bits are critical vs. non-critical.

Why can't it be opt-in instead of opt-out? Or can we have more granular control overall? On an application, module, class, function, and block level? That way my super tight hit loop that I can prove does not overflow gets a 2x speed up, while the rest of the code is safe. Oh and I can always recompile it to be always safe and analyze crashes in the real world, no t just my silly unit tests that amount to 2 + 2 == 4.

Continuing on as a default is dangerous, and has led to hundreds of thousands of security vulnerabilities. Not continuing is inconvenient, but safe.

Maybe it's time to bring back VB6 and On Error Resume Next.

It never went away, now it's just "catch (Exception) { }" spread liberally throughout the code base.

How to fix all errors in Python:

  try:
    #your code goes here
  except:
    pass

Well, technically the behavior of that is somewhat different.

One issue is that failures are not necessarily contained. An error in a less important area could still corrupt the state of something more important.

The most convincing take on this I've seen is Erlang/Elixir. You generally fail fast there, but each program is composed of many different, isolated processes. No matter how a single process fails, it won't affect any other independent processes. A stopped process only takes down those processes that depend on it, everything else continues. And Supervisors can restart the failed processes from a known good state again.

  > Being able to explicitly disable the check when you know 
  > what you want is the right balance, whether it's &+ in 
  > Swift or (better, imo) .wrapping_add() in Rust.

To clarify, Rust does disable the overflow check in release mode (and the benchmarks shown in this post are exactly why, to much heated debate), wrapping instead. `.wrapping_add()` in Rust is just what you use in order to guarantee wrapping behavior in debug mode as well (and also to guard against future changes to the language specification, which currently allows implementations to choose to either panic or wrap on overflow). In order to get the behavior of Swift's basic `+` in Rust, you'd use `.checked_add().unwrap()`.

Of course, you're right -- which is a behavior I'm even more in favor of, wherein your debug builds fail fast all the time but your release builds don't.

Reply on news.ycombinator.com