3 ms·

For one: terminating execution More importantly: why is having more than one account an "exception" at all? That's not an error or fail condition, at least in

For one: terminating execution More importantly: why is having more than one account an "exception" at all? That's not an error or fail condition, at least in my mind. I wouldn't call our use of the framework an edge case by any means, it opens a web form in which one puts authentication details, passes through the flow, and then we are given authentication tokens and the user data we need. It's not unheard of for more than one account to be returned (especially on our test devices which have many) and I get the one-account function not being suitable for handling that, my question is... why even have it then, when the multi-account one performs the exact same function, better, without an extra error condition that might arise?

TOGoS 1y ago
> why is having more than one account an "exception" at all? That's not an error or fail condition It is if the caller is expecting there to be exactly one account. This is why I generally like to return a set of things from any function that might possibly return zero or more than one things. Fewer special cases that way. But if the API of the function is to return one, then you either give one at random, which is probably not right, or throw an exception. And with the latter, the person programming the caller will be nudged towards using the other API, which is probably what they should have done anyway, and then, as you say, the returns-one-account function should probably just not exist at all.
- lazide 1y ago
  Chances are, the initial function was written when the underlying auth backend only supported a single account (structurally), and most clients were using that method. Then later on, it was figured out that multiple accounts per credential set (?!?) needed to be supported, but the original clients still needed to be supported. And either no one could afree on a sane convention if this happened (like returning the first from the list), or someone was told to ‘just do it’. So they made the new call, migrated themselves, and put in a uncaught exception in the old place (can’t put any other type there without breaking the API) and blam - ticket closed. Not that I’ve ever seen that happen before, of course. Oh, and since the multi-account functionality is obviously new and probably quite rare at first, it could be years before anyone tracks down whoever is responsible, if ever.
  - layer8 1y ago
    There’s no good way to solve this, though. Returning an arbitrary account can have unpredictable consequences as well if it isn’t the expected one. It’s a compatibility break either way.
    - lazide 1y ago
      Exactly, which is probably why a better ‘back compatibility’ change couldn’t be agreed on. But there is a way that closes your ticket fast and will compile!
      - layer8 1y ago
        Sure, but not introducing the ability to be logged into multiple accounts isn’t the best choice as well. Arguably, throwing an exception upon multiple logins for the old API is the lesser evil overall.
    - ToucanLoucan 1y ago
      > There’s no good way to solve this, though. Yes there is! Just get rid of it. It's useless. The re-implementation from using one to the other was barely a few moments of work, and even if you want to say "well that's a breaking change" I mean, yeah? Then break it. I would be far less annoyed if a function was just removed and Xcode went "hey this is pointed at nothing, gotta sort that" rather than letting it run in a way that turns the use of authentication functionality into a landmine.
      - lazide 1y ago
        I take it you’ve never had to support a widely used publicly available API? You might be bound to support these calls for many, many years.
kfajdsl 1y ago
> For one: terminating execution Seems like you should have a generic error handler that will at a minimum catch unexpected, unhandled exceptions with a 'Something went wrong' toast or similar?
zahlman 1y ago
> For one: terminating execution Not if you handle the exception properly. > why is having more than one account an "exception" at all? That's not an error or fail condition, at least in my mind. Because you explicitly asked for "the" account, and your request is based on a false premise. >why even have it then, when the multi-account one performs the exact same function, better, without an extra error condition that might arise? Because other users of the library explicitly want that to be an error condition, and would rather not write the logic for it themselves. Performance could factor into it, too, depending on implementation details that obviously I know nothing about. Or for legacy reasons as described in https://news.ycombinator.com/item?id=44321644 https://news.ycombinator.com/item?id=44321644 .

TOGoS 1y ago

> why is having more than one account an "exception" at all? That's not an error or fail condition It is if the caller is expecting there to be exactly one account. This is why I generally like to return a set of things from any function that might possibly return zero or more than one things. Fewer special cases that way. But if the API of the function is to return one, then you either give one at random, which is probably not right, or throw an exception. And with the latter, the person programming the caller will be nudged towards using the other API, which is probably what they should have done anyway, and then, as you say, the returns-one-account function should probably just not exist at all.

lazide 1y ago
Chances are, the initial function was written when the underlying auth backend only supported a single account (structurally), and most clients were using that method. Then later on, it was figured out that multiple accounts per credential set (?!?) needed to be supported, but the original clients still needed to be supported. And either no one could afree on a sane convention if this happened (like returning the first from the list), or someone was told to ‘just do it’. So they made the new call, migrated themselves, and put in a uncaught exception in the old place (can’t put any other type there without breaking the API) and blam - ticket closed. Not that I’ve ever seen that happen before, of course. Oh, and since the multi-account functionality is obviously new and probably quite rare at first, it could be years before anyone tracks down whoever is responsible, if ever.
- layer8 1y ago
  There’s no good way to solve this, though. Returning an arbitrary account can have unpredictable consequences as well if it isn’t the expected one. It’s a compatibility break either way.
  - lazide 1y ago
    Exactly, which is probably why a better ‘back compatibility’ change couldn’t be agreed on. But there is a way that closes your ticket fast and will compile!
    - layer8 1y ago
      Sure, but not introducing the ability to be logged into multiple accounts isn’t the best choice as well. Arguably, throwing an exception upon multiple logins for the old API is the lesser evil overall.
  - ToucanLoucan 1y ago
    > There’s no good way to solve this, though. Yes there is! Just get rid of it. It's useless. The re-implementation from using one to the other was barely a few moments of work, and even if you want to say "well that's a breaking change" I mean, yeah? Then break it. I would be far less annoyed if a function was just removed and Xcode went "hey this is pointed at nothing, gotta sort that" rather than letting it run in a way that turns the use of authentication functionality into a landmine.
    - lazide 1y ago
      I take it you’ve never had to support a widely used publicly available API? You might be bound to support these calls for many, many years.

kfajdsl 1y ago

> For one: terminating execution Seems like you should have a generic error handler that will at a minimum catch unexpected, unhandled exceptions with a 'Something went wrong' toast or similar?

zahlman 1y ago

> For one: terminating execution Not if you handle the exception properly. > why is having more than one account an "exception" at all? That's not an error or fail condition, at least in my mind. Because you explicitly asked for "the" account, and your request is based on a false premise. >why even have it then, when the multi-account one performs the exact same function, better, without an extra error condition that might arise? Because other users of the library explicitly want that to be an error condition, and would rather not write the logic for it themselves. Performance could factor into it, too, depending on implementation details that obviously I know nothing about. Or for legacy reasons as described in https://news.ycombinator.com/item?id=44321644 https://news.ycombinator.com/item?id=44321644 .