Behnam, thank you for submitting this ticket, our code analysis and suggestions. I really appreciate it and I am impressed with your deep diving into our implementation details. Therefore, I hope you will not feel offended if I reject your suggestions this time.

The current code works exactly as expected. This is intentional design and behavior. Please note the class name: **NonAuthUserRepositoryImpl. This NonAuth should be a hint. This class allows certain part of the code to access some, selected user's data, even if the context of the code execution is not authenticated to any user. This creates a set of very specific requirements, one of them not to allow any unintentional information leak. If the code thrown exception and application code returned an error, then this would be a way to a malicious user to get some information from our server. For example, it would allow the user to probe user's account names, what accounts exist and what account does not exist on our server. We do not want to allow for that.

Hi Artur,

Thanks for your response.

I undrestand your security conserns, but this method won't be used directly by a user, it will be used by a plugin for example, and handling this exception, is their duty. returning a correct response from your function is another thing. I think because of your method signiture (throws UserNotFoundException), your code should be aware of the exception but your code should not return error code, instead returing something like normal action or forbiden. (for example in the "JabberIqIq.java" in "tigase.xmpp.impl", you just ignore to respond. I don't see any deference between returing null and throwing exception, because they are special values (similar to before exception erra). I have a second objection, if you are agree to hide this case from plugins(any code in general), it is better to remove the throws UserNotFoundException, because your code never throws this exception and this is inconsistency (I'm not agree with removing this, plugins should know what happended underneath).

Thank you for your comments. I will review our suggestion but this change would affect larger part of the code and a general concept of handling such use-cases. Therefore, this is not something I am willing to do in rush.

I think I can handle this situation at least with Tigase-server code (If you don't mind) (as I checked about 6-7 files would be changed), the change would be setting the variable null from outside (rather than returning null), that would not have any side effects and behavioural changes. after this change, You can change the general behaviour whenever you want. (I think this change is very beneficial for future codes). [I also think this change wouldn't effects external codes, because they consider "UserNotFoundException" exception works as expected due to method signiture]