Hi, > Maruan Sahyoun <[email protected]> hat am 11. Juli 2015 um 19:56 > geschrieben: > > > Hi > > > Am 11.07.2015 um 19:44 schrieb Tilman Hausherr <[email protected]>: > > > > Yesterday user Roberto had a problem where a file wasn't saved with > > encryption. The cause turned out to be that he had called > > > > setAllSecurityToBeRemoved(true) > > > > and then > > > > protect(...) > > > > I didn't find it by looking at his code, only after debugging in save(). > > > > Although the javadoc of both calls is clear, I see a risk that this happens > > again, e.g. when people combine existing code. > > > > What should be do? Options: > > > > 1. nothing > > 2. mention the risk in javadoc > > 3. if allSecurityToBeRemoved is true in protect(), call LOG.warn("call > > setAllSecurityToBeRemoved(false) before saving or file won't be encrypted"); > > 4. if allSecurityToBeRemoved is true in protect(), throw an > > IllegalStateException > > 5. set allSecurityToBeRemoved to false when protect() is called > > > > I'm for options 3 or 4. > > I'd go for option 5 together with a warning as the call to protect() shows the > intention and add that to the javadocs. +1
BR Andreas > BR > Maruan > > > > > > Tilman > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
