Open bernaferrari opened 1 year ago
Hi @bernaferrari, when I run your code sample, I got the error below in my console. I believe you should get the error below no matter how complex the UI is.
Is your request for the error screen to be shown in this case in debug mode?
I get the error, but visually it works and only breaks in release, which is tricky.
I agree that it's tricky considering this exception is also not caught by the debugger.
I believe there are some instances where using the incorrect ParentDataWidget may show an exception on the screen, but this seems like one of the corner cases that are not captured.
I'll therefore be treating this as a bug and labeling for further investigation.
Reproducible on the latest stable and master.
Code sample can be found in https://github.com/flutter/flutter/issues/108186#issue-1315318039
To check before releasing on the store, you can run a test in release mode. If you do not have a production keystore (external customer) you can proceed with the creation of a new release keystore and modify the app/build.gradle
.
This code (see "preprod") worked for me (Flutter 3.0.4):
command line: flutter run --flavor preprod --release
signingConfigs {
debug {
storeFile file('../keystores/debug.keystore')
storePassword 'android'
keyAlias 'androiddebugkey'
keyPassword 'android'
}
releasetest {
storeFile file('../keystores/releaseTest-keystore.jks')
storePassword 'releaseTest'
keyAlias 'releaseTest'
keyPassword 'releaseTest'
}
release {
keyAlias keystoreProperties['keyAlias']
keyPassword keystoreProperties['keyPassword']
storeFile keystoreProperties['storeFile'] ? file(keystoreProperties['storeFile']) : null
storePassword keystoreProperties['storePassword']
}
}
buildTypes {
debug {
signingConfig signingConfigs.debug
}
release {
signingConfig signingConfigs.release
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
flavorDimensions "flavor-type"
productFlavors {
dev {
dimension "flavor-type"
applicationIdSuffix ".dev"
}
preprod {
dimension "flavor-type"
buildTypes.release.signingConfig signingConfigs.releasetest
}
prod {
dimension "flavor-type"
}
}
I faced the same issue, any solution?
It would be useful if some visual mark like a color overlay was added to the component that throws this exception so that it can be visually determined which widget is the one that is defective
Could "lint" flag this error ?
The main issue here is that because of this bug what seems to work during development in debug mode suddenly fails in production in release mode. The developers have faith in the Flutter framework to at least render what was rendered in debug mode in release mode as well.
It seems Flutter is ignoring it on purpose to avoid other rendering issues by adding the ErrorWidget, but honestly, the current behavior is leading to misassumptions given in debug mode everything looks ok on the UI. For sure there might be a better way of handling it.
@goderbauer @Hixie Is there another way to handle such scenarios in the current state of the framework? Relying on debuggers to catch it is not safe enough. A lint rule maybe? It would prevent people from causing it but still have a bad error report on debug mode if any edge case happens. A bit more context would allow me to contribute here.
I think
Column(Padding(Expanded))
should fail in debug mode, because it is ultra hard to debug it is wrong in release mode in a complex layout: