> On Jan 6, 2016, at 1:12 PM, Don Wills <don.wi...@portablesoftware.com> wrote:
>
> It also means that every third party API provider will *never* be able to
> change any method signature from failable to non-failable or vice-versa.
> That is a really bad thing!
API consistency is a good thing. A method that can fail is fundamentally
different than the same method without failure — it’s comparable to adding
another return value, or an ‘out’ parameter, both of which we would expect to
be a breaking API change. Sneaking in unchecked exceptions is like saying “oh
yeah, starting in version 3.5, calling this method might suddenly abort your
flow of control and take you to back the nearest catch block, even though you
didn’t think it could do that. I hope that’s not a problem.” (Reminds me of the
way PHP introduces catastrophic API behavior changes under the hood in minor
releases…)
If you do end up needing to add errors to an API method, you can do it by
adding a new variant of the method that throws, deprecating the old version,
and then removing the old one once clients have migrated.
—Jens
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
