Skip to content

Hide "this could be a framework bug" message when first stack frame is not framework #18412

Closed

Description

@Hixie

We should hide the message saying this could be a framework bug if the first stack frame is not in the framework. In fact we should probably figure out which package is to blame and then explicitly name that.

Depends on #4021.

Activity

  1. added
    c: crashStack traces logged to the console
    frameworkflutter/packages/flutter repository. See also f: labels.
    a: qualityA truly polished experience
    on Jun 12, 2018
  2. added this to the milestone on Jun 12, 2018
  3. eduardkieser commented on Jun 27, 2018

    @eduardkieser
  4. self-assigned this
    on Jul 9, 2018
  5. gspencergoog commented on Jul 9, 2018

    @gspencergoog
    Contributor

    @eduardkieser I don't think that is related to this issue: your stack trace starts within the framework, and doesn't have the "this could be a framework bug" message either.

    I'm going to hide your comment (since it's irrelevant to this issue and long). If you're still having trouble, please ask on StackOverflow or file a new issue with a reduced test case.

  6. mit-mit commented on Sep 20, 2018

    @mit-mit
    Member

    Hi @gspencergoog did you get a chance to look at this? I just tried to re-repro #16260, and I still see it.

  7. gspencergoog commented on Sep 20, 2018

    @gspencergoog
    Contributor

    No, I haven't looked at this yet, but I'll look at it soon.

  8. removed their assignment
    on Jul 10, 2019
  9. dnfield commented on Jan 7, 2020

    @dnfield
    Contributor

    I'm going to look at this.

    I'd like to amend the logic as follows:

    1. Be a little bit less sensitive to dart changes in the stack. Since we wrote this logic, Dart added new frames/indirections into the assertion error throw.
    2. Check to see if the next frame after the assert is non-framework code. If so, I'm going to say it's not our fault, but that the user is passing us bad values. If not, then we either need to add an assert higher up in the framework (e.g. a hypothetical widget that should assert a label value is not null before trying to create a Text widget with the label), or we need to fix some garbage in the framework (e.g. a hypothetical scroll view that messes up some sliver rules).
  10. self-assigned this
    on Jan 7, 2020
  11. github-actions commented on Aug 15, 2021

    @github-actions

    This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

  12. locked as resolved and limited conversation to collaborators on Aug 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

a: qualityA truly polished experiencec: crashStack traces logged to the consoleframeworkflutter/packages/flutter repository. See also f: labels.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions