You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An error is returned: "Cannot override non-throwing initializer with throwing initializer." This error seems spurious:
Initializers aren't inherited, so why does it matter if an initializer has the same signature as one of the superclass's? None of the superclass initializers can even be called outside of a 'super' call in one of our initializers, so for the most part they're living in entirely independent fiefdoms.
This isn't really even an override; init?(url🙂 translates to initWithURL:, whereas init(url🙂 throws translates to initWithURL:error:. Two entirely different signatures, and a pattern that would have worked without incident in Objective-C.
The unfortunate end result of this situation is that one either has to lose error information in failure conditions, or give the initializer a suboptimal name.
The text was updated successfully, but these errors were encountered:
The override part is still significant because of convenience initializers. If a class overrides all designated initializers in its superclass, it inherits any convenience initializers. In this situation, we'd probably want some kind of nonoverride attribute or modifier that acknowledges the similarity between the two initializers but chooses to ignore it. (This kind of answer would have to go through the Swift Evolution Process.)
Environment
Xcode 9 beta 2
Additional Detail from JIRA
md5: 2605a0fa960b3efb9453ee44061951fe
is duplicated by:
Issue Description:
So, suppose you want to make a subclass of, say, InputStream, and initialize it to a URL, like so:
An error is returned: "Cannot override non-throwing initializer with throwing initializer." This error seems spurious:
Initializers aren't inherited, so why does it matter if an initializer has the same signature as one of the superclass's? None of the superclass initializers can even be called outside of a 'super' call in one of our initializers, so for the most part they're living in entirely independent fiefdoms.
This isn't really even an override; init?(url🙂 translates to initWithURL:, whereas init(url🙂 throws translates to initWithURL:error:. Two entirely different signatures, and a pattern that would have worked without incident in Objective-C.
The unfortunate end result of this situation is that one either has to lose error information in failure conditions, or give the initializer a suboptimal name.
The text was updated successfully, but these errors were encountered: