[mercury-users] design of stream library
Peter Ross
peter.ross at miscrit.be
Mon Sep 4 22:31:00 AEDT 2000
On Mon, Sep 04, 2000 at 09:35:26PM +1100, Michael Day wrote:
>
> > However this doesn't interact well with exceptions. Say you have a bit
> > of code which outputs to a stream but might throw an exception, you wrap
> > it in an exception handler and you then want to clean up the stream, but
> > you no longer have a handle with which to refer to the stream.
>
> What is the situation, exactly? The streams at present have no real error
> handling capability, but perhaps the exception could be caught within
> write_char rather than propagated out, and some error state toggled in the
> stream?
>
but the exception may come not be thrown inside a stream predicate.
For example
( { List = [X | _] } ->
write_char(X)
;
throw("empty list")
)
> What guarantees should code provide regarding exceptions?
>
Not much in the presence of synchronous exceptions (ie those which are
thrown in well defined places). Asynchronous execptions (like the user
pressing Ctrl-C) are more problematic because you can't guarantee when
they will be generated so you need to safeguard groups of operations
which must be atomic. AFAIK Mercury doesn't support asynchronous
exceptions yet.
> Are there any issues to keep in mind when designing interfaces to be
> exception friendly?
>
The only one I have encountered so far is that exceptions and unique
modes don't seem to interact well.
Pete
--------------------------------------------------------------------------
mercury-users mailing list
post: mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe: Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------
More information about the users
mailing list