basically, someone's going to have to go through all the usages of the standalone field parsing foo in all the james libraries and explicitly catch IllegalArgument exceptions. the rest of Mime4J throws checked exceptions when parse problems are encountered so everytime that these classes are used, developers are going to need to remember to catch that exception. so, i think that at the very least, a strong warning is required in the release notes.
if you don't like the checked exception, the other field subclasses use getParseException. i don't love this design but it would be more consistent if this convention was used to handle this use case. - robert On Thu, Jan 8, 2009 at 7:44 PM, Robert Burrell Donkin (JIRA) <server-dev@james.apache.org> 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). > > 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. 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. > >> 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: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
