6 ms·

I disagree. While, yes, Facebook needs to test their SDK, app developers need to build resiliency into their apps to ensure third party dependencies don’t break

I disagree. While, yes, Facebook needs to test their SDK, app developers need to build resiliency into their apps to ensure third party dependencies don’t break their app. The developer adopted it into their app; it’s their responsibility to do the proper checks in cases like these where Facebook broke things on their end.

corndoge 6y ago
Ah yes. If hacker news goes down while you are writing this comment, it is your responsibility to ensure you can still post your comment despite the service breakage.
- slipheen 6y ago
  Unless your app is designed for browsing Facebook, there's no reason that anything on Facebook's servers should affect if your app works. Many of the apps crashing are using Facebook for a portion of their app, such as one login option. Letting that take down the whole app is insufficiently defensive coding, whether in the app, sdk, or glue between them.
  - corndoge 6y ago
    How do you defend against abort() in library code?
    - Nextgrid 6y ago
      Don't include libraries which contain such code?
      - saagarjha 6y ago
        No abort here, the crash is coming from the runtime, which you’re not opting out of if you want your app to work.
        slipheen 6y ago
        Then we can agree the FB sdk should have been better written to avoid this, right?
        corndoge 6y ago
        Obviously, and now we agree!
  - frenchy 6y ago
    > there's no reason that anything on Facebook's servers should affect if your app works. Absolutely, but the problem is that in order for you to use these features, you're supposed to use the official Facebook SDK. The additional problem, is that Facebook has no interest in defensive coding, because if you're not interacting with Facebook in an app, there's no benefit to Facebook for you using that app at all.
yreg 6y ago
So how could the app developers have prevented this, other then not using the SDK? (I'm not advocating for using the SDK.)
- mattgreenrocks 6y ago
  Would disabling SDK autoinit have fixed this? That was a suggestion raised back in March. Seems like a net win to avoid static initializers in the first place. (Am not a mobile dev, but it wasn't exactly hard to find that, either).
  - Sephiroth87 6y ago
    Maybe (although some people report that not working), but not necessarily, as "autoinit" is just an if case checked in the same auto executed code in the Facebook SDK, which could still crash before the flag is checked.
monocularvision 6y ago
This is a native SDK that is crashing the process. There is nothing an app developer can responsibly do to prevent or recover from this crash. Other than remove the SDK, of course.
- XCSme 6y ago
  So there is no way to try {} catch {} it, right?
  - Sephiroth87 6y ago
    Not in this case, as it's not code explicitly called by the client, but automatically loaded on app launch...
  - valuearb 6y ago
    If it's an objective C exception, you can catch those with an objective c wrapper function. Ive done that before in my Swift projects.
  - saagarjha 6y ago
    Yes, but 1. it’s hard to inject that as the crash happens very early at launch and 2. Objective-C exceptions of this type are not intended to be caught.
    - robterrell 6y ago
      That's not strictly true, and anyway it's different for the app developer versus a library provider. If you're making a 3rd party SDK that can throw, you need to make it can catch those throws.
      - saagarjha 6y ago
        NSInvalidArgumentException is not intended to be caught. You can, of course, but receiving one indicates a serious run-time error.
- 6y ago

corndoge 6y ago

Ah yes. If hacker news goes down while you are writing this comment, it is your responsibility to ensure you can still post your comment despite the service breakage.

slipheen 6y ago
Unless your app is designed for browsing Facebook, there's no reason that anything on Facebook's servers should affect if your app works. Many of the apps crashing are using Facebook for a portion of their app, such as one login option. Letting that take down the whole app is insufficiently defensive coding, whether in the app, sdk, or glue between them.
- corndoge 6y ago
  How do you defend against abort() in library code?
  - Nextgrid 6y ago
    Don't include libraries which contain such code?
    - saagarjha 6y ago
      No abort here, the crash is coming from the runtime, which you’re not opting out of if you want your app to work.
      - slipheen 6y ago
        Then we can agree the FB sdk should have been better written to avoid this, right?
        corndoge 6y ago
        Obviously, and now we agree!
- frenchy 6y ago
  > there's no reason that anything on Facebook's servers should affect if your app works. Absolutely, but the problem is that in order for you to use these features, you're supposed to use the official Facebook SDK. The additional problem, is that Facebook has no interest in defensive coding, because if you're not interacting with Facebook in an app, there's no benefit to Facebook for you using that app at all.

yreg 6y ago

So how could the app developers have prevented this, other then not using the SDK? (I'm not advocating for using the SDK.)

mattgreenrocks 6y ago
Would disabling SDK autoinit have fixed this? That was a suggestion raised back in March. Seems like a net win to avoid static initializers in the first place. (Am not a mobile dev, but it wasn't exactly hard to find that, either).
- Sephiroth87 6y ago
  Maybe (although some people report that not working), but not necessarily, as "autoinit" is just an if case checked in the same auto executed code in the Facebook SDK, which could still crash before the flag is checked.

monocularvision 6y ago

This is a native SDK that is crashing the process. There is nothing an app developer can responsibly do to prevent or recover from this crash. Other than remove the SDK, of course.

XCSme 6y ago
So there is no way to try {} catch {} it, right?
- Sephiroth87 6y ago
  Not in this case, as it's not code explicitly called by the client, but automatically loaded on app launch...
- valuearb 6y ago
  If it's an objective C exception, you can catch those with an objective c wrapper function. Ive done that before in my Swift projects.
- saagarjha 6y ago
  Yes, but 1. it’s hard to inject that as the crash happens very early at launch and 2. Objective-C exceptions of this type are not intended to be caught.
  - robterrell 6y ago
    That's not strictly true, and anyway it's different for the app developer versus a library provider. If you're making a 3rd party SDK that can throw, you need to make it can catch those throws.
    - saagarjha 6y ago
      NSInvalidArgumentException is not intended to be caught. You can, of course, but receiving one indicates a serious run-time error.
6y ago