[ https://issues.apache.org/jira/browse/MAILBOX-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256567#comment-13256567 ]
Jochen Gazda commented on MAILBOX-175: -------------------------------------- >>> not sure, but is the caller gives a null, that's not good, and maybe we >>> should runtimeexception >> >> Yes, for both name and namespace attributes, I propose NPE. > > I would have thrown IllegalArgumentException OK, be it IllegalArgumentException. >>> or maybe you have a usecase for null parameters? > >> I do not have any. Client code should be fixed. > > Will you fix it? (when you say 'client', I guess you mean the other james > modules). Yes, I am doing my best now to fix the callers. > Make the contract of MailboxPath explicit and documented. > --------------------------------------------------------- > > Key: MAILBOX-175 > URL: https://issues.apache.org/jira/browse/MAILBOX-175 > Project: James Mailbox > Issue Type: Sub-task > Components: api > Reporter: Jochen Gazda > Assignee: Jochen Gazda > > Make the contract of org.apache.james.mailbox.model.MailboxPath explicit and > documented. > Points to consider: > (1) Make all attributes immutable - can be done quite easily, no discussion > expected. > (2) Null values should be forbidden for at least for name and namespace > attributes - NullPointerException will be thrown from constructors. A lot of > client code uses e.g. getName().length(). Clients should be responsible for > the proper values when creating new instances of MailboxPath. > (3) Consider adding a delimiter field. Currently delimiter is implicitly > present in the name value anyway. It would allow: > (3.1) removing the delimiter parameter from getHierarchyLevels() > (3.2) adding relativePath(relativeName) method (which is currently done by > concatenating path segments with bona fide default delimiter in the client > code). > (3.3) name attribute could guarrantee that it does not start with delimiter > (which is sometimes checked in the client code now). For names starting with > delimiter, either > (3.3.a) constructors should throw IllegalStateException or > (3.3.b) the name attribute would be rewritten silently - should perhaps > be prefered, because of the existing client code. > (3.4) Currently, there is no delimiter escaping/unescaping (e.g. in parse() > or getHierarchyLevels()). Should there be any? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org