On 2/24/16, 12:08 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote:
>Hi Alex, > >that sounds as if you are using assertions in a way that contradictory to >what they are intended to be used. It isn't me. I did not write this code or review it. Before Flex moved to Apache, I had made maybe a half-dozen changes to one Java file in what is now flex-sdk, and attempted some changes in the MXMLClassDirectiveProcessor in flex-falcon. I had not even looked at most of the Falcon code. I'm learning Java as needed. >Assertions are meant to be hard checks to the contract of a method. >Assumptions the code needs to operate correctly. >Usually you could do the same with if-statements, but in contrast to >using normal checks, assertion code is skipped if assertions are >disabled. They are usually skipped in production systems. The main >intention of assertions is to fail fast and hard if something is not as >expected. This is true during development and especially during the >execution of unit-tests. > >So I think there are to options here: >1. The assertions are not correct and the code could actually work with >the failing condition >2. The test is not correct. > >In the case I investigated, there is a namespace declaration without any >namespace. The check failing, fails because "the quotes have been removed >while parsing the expression" ... well there is no expression, so it >doesn't contain quotes. I would rather check if there is an expression >first. If a namespace declaration has no definition, then the expression >should be invalid and not complain that it doesn't have quotes. > >So I strongly object to switching assertions off in unit tests. If we do, >we should remove them all together. That's fine. You are welcome to turn them on and upgrade the asserts. My take away is that the asserts did not take into account some degenerate cases (when null is passed in) so maybe the asserts just need to test for null and not fail. -Alex
