-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
assertionFailure()
as opposed to fatalError()
#85
Comments
The general problem with replacing |
I don't use the Router myself, so I wonder what kinds of situations make you run into the |
Well it concerned Routables which didn’t always implement all screens. And the function expected to return a routable and so we’d hit our fatalError() The way I ended up doing it was blocking any operation if canPush/canPop returned false etc. seems to work well. |
Hello,
In my own fork of this project, I've gone ahead to remove all references to
fatalError()
in my use of the Router. This warranted a change to the router itself, to prevent any operations from occurring if I everreturn nil
from thepushRouteSegment
orchangeRouteSegment
functions. I have manually popped the route from the stack if we ever hitnewState()
with an invalid route.Is this the correct way to do this? I would like some further clarification too on why
fatalError()
was chosen as opposed toassertionFailure()
which would be evaluated in DEBUG builds only. The situation we faced was the occasional (widespread) crash in the Routables in our release builds which was horrendously detrimental to our user experience.I am happy to make a pull request for this too. Otherwise a discussion would be great! 🙌
The text was updated successfully, but these errors were encountered: