Private exceptions

Private exceptions

[Alessandro Baretta]

I have a come across the following situation: I have a relatively complex 
algorithm where exception management SHOULD occur only at the outermost function 
call. I have managed to create a rather nasty bug by inadvertently recursing 
through a function which captures exceptions coming from the inner recursive and 
does not propagate them upwards.

In this situation, I'd like to be able to declare an exception "private" to a 
module, such that that exception can only be matched within the scope of the 
exception declaration. I am currently sidestepping the problem by using an 
exception which is not exported by the defining module, and consequently cannot 
be matched explicitly, but it can be matched by a try <expr> with _ -> <whatever>.

Am I the only one with this kind of need?

Alex

Re: [Caml-list] Private exceptions

[Eric Cooper]

On Mon, Jan 30, 2006 at 03:31:56PM +0100, Alessandro Baretta wrote:
> [...]
> In this situation, I'd like to be able to declare an exception "private" to 
> a module, such that that exception can only be matched within the scope of 
> the exception declaration. I am currently sidestepping the problem by using 
> an exception which is not exported by the defining module, and consequently 
> cannot be matched explicitly, but it can be matched by a try <expr> with _ 
> -> <whatever>.

But the ability to match any exception (and re-raise it, without
knowing anything more about it) is essential for implementing
constructs like "unwind-protect", "with-open-file", suspend/force,
etc.

-- 
Eric Cooper             e c c @ c m u . e d u

Re: [Caml-list] Private exceptions

[Alessandro Baretta]

Eric Cooper wrote:
> On Mon, Jan 30, 2006 at 03:31:56PM +0100, Alessandro Baretta wrote:
> 
> But the ability to match any exception (and re-raise it, without
> knowing anything more about it) is essential for implementing
> constructs like "unwind-protect", "with-open-file", suspend/force,
> etc.

You are right, I must admit. Yet the problem remains. There are times when 
catching exceptions is unsafe. In my case, the exception aborts a database 
transaction. If the exception is not propagated to the calling transaction 
manager call, this will continue to execute the current transaction outside of 
the transaction block--as a rollback has already been issued.

Now, of course there is never only one way to solve a given programming problem, 
and I did solve mine without tampering with the exception system too 
much--except that I no longer export the exception signalling a transaction 
rollback, so that at least it cannot be *explicitely* filtered.

Alex


-- 
*********************************************************************
http://www.barettadeit.com/
Baretta DE&IT
A division of Baretta SRL

tel. +39 02 370 111 55
fax. +39 02 370 111 54

Our technology:

The Application System/Xcaml (AS/Xcaml)
<http://www.asxcaml.org/>

The FreerP Project
<http://www.freerp.org/>