On Thu, Jan 8, 2009 at 8:44 PM, Robert Burrell Donkin (JIRA) <[email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/MIME4J-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662087#action_12662087 > ] > > Robert Burrell Donkin commented on MIME4J-90: > --------------------------------------------- > > I don't seem to have done a very good job of explaining the issue. > > Using runtime exceptions make things difficult for correct protocol > implementations. Typically, protocols have their own in-protocol error > reporting systems. It is expected that exceptions will be checked so that > developers can caught and correctly handle all expected known issues. Runtime > exceptions are assumed to be fatal to the session and will typically result > in the socket disconnecting (for security reasons, it's unwise to continue > after a programming error).
Just to make sure I understand your concern correctly: You mean protocol implementations that invoke Field.parse() directly? Because if the protocol implementation uses a MimeStreamParser this cannot be an issue because AbstractEntity makes sure that the precondition of Field.parse() does not get violated. > These are public classes and form a public API. The runtime was replaced by a > checked exception to allow these classes to be safely used in protocol work > in a standalone fashion. Again, standalone as in "not driven by MimeStreamParser/ContentHandler"? >Reverting this design decision is a potentially dangerous decision since >protocol implementations may be relying on the checked exception to correctly >handle that condition. Upgrading will break any protocols which made this >assumption. > > When breaking the contract of a public API, it is better to do this in a > cleanly incompatible way. If this is not possible then it must be highlighted > in the release notes. What would you think about keeping the checked exception in Field.parse() and adding a second method that throws an IllegalArgumentException instead? That second method could be used for creating or manipulating messages. Because for this use case the checked exception is really a PITA. Markus > >> Consistent parsing of header field names >> ---------------------------------------- >> >> Key: MIME4J-90 >> URL: https://issues.apache.org/jira/browse/MIME4J-90 >> Project: JAMES Mime4j >> Issue Type: Bug >> Affects Versions: 0.5 >> Reporter: Markus Wiederkehr >> Priority: Minor >> Fix For: 0.6 >> >> Attachments: mime4j-fieldname.patch >> >> >> RFC 822 defines a field as: >> field = field-name ":" [ field-body ] CRLF >> field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":"> >> This implies that a field name must consist of at least one character and >> may not contain spaces or tabs; not even trailing ones. >> Currently o.a.j.mime4j.parser.AbstractEntity#parseField accepts empty field >> names while o.a.j.mime4j.field.Field#parse accepts trailing spaces and tabs. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
