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 22:41:35 GMT
On Thu, Jan 8, 2009 at 11:05 PM, Robert Burrell Donkin
<robertburrelldonkin@gmail.com> wrote:
> On Thu, Jan 8, 2009 at 9: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
>> Again, standalone as in "not driven by MimeStreamParser/ContentHandler"?
> Yes
> Field.parse is public and so is part of the public API (though perhaps
> this should be reconsidered)

I think one way or another it has to stay that way. How else would it
be possible to create a DOM from scratch?

>>>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.
> that was one of my suggestions, or alternatively just rename parse
> without replacement so that it's clear the contract has change.
> but maybe it would be better to quickly reconsider the general design
> in this area (i'm not a fan)

Okay, for now I have attached a patch to MIME4J-90 that should resolve
the issue. If we decide to overhaul the design it can be done in
another JIRA..

What alternative do you have in mind?

> if the general design is retained (i'd be happy enough to see it
> revised without regard to compatibiltiy), these questions might be
> worth thinking about:
> 1. should the parsing methods be part of the general public API?

I believe yes because it's not feasible to write high-level setters
for each and every possible header field. How would you set an
X-header without some low-level operations, for example?

> 2. if so, most Field subclasses store ParseException (in a property)
> when something goes wrong. would it be worthwhile adopting this into
> the general contract?

Absolutely yes. The only problem seems to be that currently there is
not one ParseException but five or so. These are generated by Javacc
for each field type. We could chain these exceptions to a generic
parse exception, of course..


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

View raw message