Instead we're going to move back to standard exceptions.
Using a custom Result class has created far far more problems
- The Stacktraces aren't always right
- Sometimes one forgets to check the Result error
- All other exception throwing code needing to be converted to Results
- Non idiomatic Dart code
I think it's better to just go back to exceptions. They have their
problems, but overall, I think it's a better approach.
Not everywhere, but a large part of the code base.
This way, hot reloading will also reload the strings which makes for
such a better developer experience.
Now that dart-code-metrics has been updated, this lint can finally be
used. So far all of these are false positives, in the sense that I don't
care about their return values.
I wish there was an easy way of marking functions whose return value
shouldn't ever be ignored.
We now have a list of all the features that are implemented, and we can
use that to show a kind of feature list which can be used to -
1. Move away from app rental model
2. Showcase a feature list; see WorkingCopy
Make it a ChageNotifier and try to access it through the Provider
instead of like a global variable. This way, the state is better
managed and it'll be easier to split out Settings into smaller classes.
