Better Error Warning when using private attributes in EpoxyModel

[vdubedout]

Hi there,

I wrote some attributes with the private modifier @EpoxyAttribute private lateinit var htmlText: String (conditioned reflex, my bad) and I had a weird error that took me way too much time to link to the private modifier. I don't know if it's possible to verify this and display a better error than:
<identifier> expected and not a statement. I was searching an eventual conflict in my gradle or a problem in kapt.

[elihart]

Thanks for reporting. Java should accurately provide a good error message for this, but I suppose Kotlin handles it differently. I'll try to get this addressed soon

[geralt-encore]

I just checked and the same happens in Java as well. The actual error message is at the very bottom. So the problem is not that there is no proper error message, but that processor is still trying to generate something even though some error has occurred. Seems like this problem exists not only for this case but pretty much for all of them since during validation steps we are just logging errors and not throwing actual exceptions so control flow is not interrupted.

[vdubedout]

More info, there is an error in Kotlin and Java at the bottom, up to two private attributes. Starting from 3 attributes there is no explicit error anymore.

Java File 1 private attribute -> error

Kotlin File 1 private attribute -> error

Kotlin file 2 private attribute -> error

Kotlin file 3 private attribute -> no more explicit errors

Java file 3 private attributes -> no more explicit errors

[geralt-encore]

The number of attributes doesn't really matter. It truncates because Java compiler has 100 errors limit by default.

[elihart]

Good analysis. The reason we still try to generate code even though we log this error is that without generating the code there is the possibility for hundreds of more errors where referenced generated files don't exist, and that makes it even harder to find the original issue.

I will try to clean up the code generated in this case.

[elihart]

Fix #388

The main issue was that since we didn't have the name of the setter/getter we used "null" which made the generated code all messed up. The fix is simple. It switches the field to be accessed directly like super.html = html. This will give an error that html is private and can't be accessed, but it is much clearer.