On Sun, Nov 9, 2008 at 9:50 PM, Markus Wiederkehr
<[EMAIL PROTECTED]> wrote:
> On Sun, Nov 9, 2008 at 10:35 PM, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
>> I personally prefer a subclass of Throwable to express some kind of
>> exceptional condition, but could live with InvalidField or some such.
>
> Mime4j does not throw an exception if a date header field is
> malformed. The same is true for erroneous address lists, mailboxes and
> mailbox lists.
the mime4j API is inconsistent. the other fields expose any exception
using a getter. i suspect that this design was adopted to allow the
caller to decide whether they wanted to ignore unparsable fields or
not.
the consistent way to remove the throws clause would be to pull the
getter up from the subclasses. the major problem with this approach
would be to break callers relying on catch blocks which would need to
be replaced with a getter check.
> Wouldn't it be consequent not to throw an exception if a header field
> does not match the required regex?
>
> Another possible solution would be:
>
> public static Field parseUnchecked(final String raw) throws
> IllegalArgumentException {
> // ...
> }
>
> public static Field parse(final String raw) throws MimeException {
> try {
> return parseUnchecked(raw);
> } catch (IllegalArgumentException e) {
> throw new MimeException("Invalid header field", e);
> }
> }
>
> I'm not sure if I like that either..
i would prefer not to use a RuntimeException. a getter would be more
consistent with the rest of the API.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
