Hacker News Reader

Comment by flipgimble | Hacker News Reader

The critical difference is that in swift your have to override safe behavior by using special syntax. This means you can search for it to fix it, you can have compiler/linters enforce certain rules, you can catch it easily in code reviews. No professional team I've worked on would allow forced unwrapped code except in special well documented cases.

The default code you write in swift is safe. You spend less time worrying about its correctness, which means you can focus on solving higher level problem and less time debugging.

When people call swift pedantic, for example, and I take time to ask for the specifics, I mostly get "not familiar to me", or "I'm used to shooting myself in the foot and unwilling to consider alternatives". So my patience has run out.

View on HN

If only there was a way to catch array index out of bounds.

  extension Collection {
    subscript (safe index: Index) -> Element? {
      return indices.contains(index) ? self[index] : nil
    }
  }

And now you have the choice:

  array[i] // traps for invalid indices
  array[safe: i] // returns nil for invalid indices

I always have a choice if I'm the one writing the code.

But what I want is a way to catch all errors that others may have introduced in code I have no control over. That includes arithmetic overflow as well.

What would you do? If the ordinary array subscript produced an optional value, people would simply fall into the habit of force-unwrapping it, since the hassle of handling the spreading optionals would be too big. And throwing an unchecked exception would lead to empty catch blocks everywhere, just as in Java. And then the execution would continue in God only knows what state. I simply don’t think that the type system can solve the question of trusting your dependencies for you.

What I want to do is to wrap a piece of code running in its own thread in a catch block so I can respond gracefully to any errors without killing the entire process.

What gracefully means depends entirely on the application. Often it means to log the error or display a meaningful error message if it's an interactive app, then maybe do other kinds of cleanup and shut the thread down.

It can also mean to retry later. Array out of bounds errors are quite often just a result of not properly handling an earlier temporary error.

Whether or not errors leave the rest of the application in an inconsistent state depends entirely on the design of the application.

I'm not saying that letting an app crash on buggy code is never the right thing to do. I just want the option to handle it differently where appropriate and possible (it's not always possible anyway).