On 1/8/09, Markus Wiederkehr <markus.wiederk...@gmail.com> wrote: > On Thu, Jan 8, 2009 at 11:05 PM, Robert Burrell Donkin > <robertburrelldon...@gmail.com> wrote: >> On Thu, Jan 8, 2009 at 9:23 PM, Markus Wiederkehr >> <markus.wiederk...@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"? >> >> 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?
By making the API internal to Mime4J. One way would be to use packaging and (if possible) access to indicate this to users of the library. > >>>>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.. I'll take a look this weekend > 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? One strategy would be for the high level API to expose general, user friendly methods which use the internal API >> 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.. IIRC the exceptions can be consolidated into a single hierarchy by editing the JavaCC source. If this sounds worthwhile, I'll take a look at this sometime soon (unless someone beats me to it) - Robert > > Markus > > --------------------------------------------------------------------- > 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
