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
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 ever return nil from the pushRouteSegment or changeRouteSegment functions. I have manually popped the route from the stack if we ever hit newState() 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 to assertionFailure() 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:
The situation we faced was the occasional (widespread) crash in the Routables in our release builds which was horrendously detrimental to our user experience.
The general problem with replacing fatalError() with assertionFailure() is that you are replacing a crash, which comes with accompanying debug information to help you fix the crash, with undefined behavior. That undefined behavior could be just as bad or worse than a crash from a UX perspective, and you'll have no idea when it is happening to your users.
I don't use the Router myself, so I wonder what kinds of situations make you run into the fatalError conditions in the live app. At best, this should not happen at all. @jondwillis point is valid, so maybe it'd be better to change the approach of the Router in general if it is error-prone than just removing the crashes.
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: