james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Markus Wiederkehr" <markus.wiederk...@gmail.com>
Subject Re: [jira] Commented: (MIME4J-90) Consistent parsing of header field names
Date Thu, 08 Jan 2009 21:39:56 GMT
On Thu, Jan 8, 2009 at 10:23 PM, Markus Wiederkehr
<markus.wiederkehr@gmail.com> wrote:
> On Thu, Jan 8, 2009 at 8: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).
> 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.

How about adding Field.parse(String fieldName, String fieldBody)?


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message