Re: [Classpath-inetlib] Sending SMTP message gets stuck upon exception

[Øyvind Harboe]

søn, 25.01.2004 kl. 17.13 skrev Chris Burdess:
> Øyvind Harboe wrote:
> >> You cannot assume that you can safely call any method on the 
> >> transport,
> >> including close(), after an I/O error.
> >
> > What should my code do then?
> >
> > Isn't the "physical" SMTP connection still open?
> >
> > Garbage collection doesn't close it.
> 
> You can specify a socket timeout in the session properties, which will 
> take care of the socket.

This sort of thing gives me the shivers. 

How can I know that I've set *all* the properties to the "right" values?

I'm getting up on my soapbox now:

Flexibility and configurability sucks when it is used to pass the buck 
instead of putting issues to bed in the API and the implementation of
the APIs.

When I use an API, it is because I don't want to know anything about
e.g. SMTP and UTF8 encoding.

> >> If you can provide a good reason
> >> why you think we /should/ be able to recover from such errors, let me
> >> know and I'll look into it.
> >
> > This API is defined by Sun AFAICT.
> >
> > However, the API doc is not terribly  helpful in specifying whether or
> > not close() should be called in all cases.
> 
> I know. I'll look at trying to tidy this up in the provider.

What is your interpretation?

Should I or should I not call close() on Transport?

If you take javax.comm as example (Serial port communications), you
*must* call close() to free up the serial port.

Øyvind