exception Failure and failwith

exception Failure and failwith

[Luca Pascali]

Hi everyone.

I've ran into a situation and I need a little explanation.

It's all about the failwith function of pervasives (that simply raises 
an exception Failure of string).
Normally, that exception can be cought by means of a try...with using as 
clause something like
| Failure s -> .....

That's good.
But what if I define something (another exception like module Stream 
does), a constructor (like I did) with the name Failure?

Obviously the Ocaml type checker will make all controls with the new 
definition of Failure (starting from that point).
But what if I want to catch the Failure exception? :-/
It seems that no module defines it, so I did not find any way to 
identify the exception.

Thanks to everyone
Luca

-- 
*********************************************************************
Luca Pascali
luca@barettadeit.com
asxcaml-guru@barettadeit.com

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

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

Our technology:
http://www.asxcaml.org/
http://www.freerp.org/


	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it

Re: [Caml-list] exception Failure and failwith

[Luc Maranget]

> Hi everyone.
> 
> I've ran into a situation and I need a little explanation.
> 
> It's all about the failwith function of pervasives (that simply raises 
> an exception Failure of string).
> Normally, that exception can be cought by means of a try...with using as 
> clause something like
> | Failure s -> .....
> 
> That's good.
> But what if I define something (another exception like module Stream 
> does), a constructor (like I did) with the name Failure?
> 
> Obviously the Ocaml type checker will make all controls with the new 
> definition of Failure (starting from that point).
> But what if I want to catch the Failure exception? :-/
> It seems that no module defines it, so I did not find any way to 
> identify the exception.
> 
> Thanks to everyone
> Luca
> 
> -- 

Failure is considerd 'internal' (or built-in, or predefined) by the compiler.
The same applies for instance to the 'option' type constructors None
and Some.

Have a look at the manual
<http://caml.inria.fr/pub/docs/manual-ocaml/manual033.html#htoc249>

You could have expected that 'Failure' is defined in standard library
(eg in module Pervasives) but it is not the case.

So the answer is: tou can't.
If you shadow OCaml's Failure by your definition, then
you have no longer access to OCaml's Failure.


-- Luc Maranget

Re: [Caml-list] exception Failure and failwith

[Luca Pascali]

Luc Maranget wrote:

> [...]
>
>Failure is considerd 'internal' (or built-in, or predefined) by the compiler.
>The same applies for instance to the 'option' type constructors None
>and Some.
>
>Have a look at the manual
><http://caml.inria.fr/pub/docs/manual-ocaml/manual033.html#htoc249>
>  
>
I missed it, now I've seen.

>You could have expected that 'Failure' is defined in standard library
>(eg in module Pervasives) but it is not the case.
>
>So the answer is: tou can't.
>If you shadow OCaml's Failure by your definition, then
>you have no longer access to OCaml's Failure.
>-- Luc Maranget
>  
>
It's what I was afraid of.
I got it. Anyway let me make a consideration: It would be nice to have a 
way (a fake module named Core,for example) to access the core types, 
exception and definitions in case someone shadows the original one.

For example if you open Stream module, it redefines the Failure exception.
I will try to avoid this kind of job, but there are already some 
external modules that do this.

Since I received answers only directly, I would like to forward also the 
answer I got from  Julien Signoles, that suggests to define an exception 
with a new name, equal to the old one

exception Prim_Failure = Failure

to get rid of any further shadowing.

Thanks for the answers.

Luca

-- 

*********************************************************************
Luca Pascali
luca@barettadeit.com
asxcaml-guru@barettadeit.com

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

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

Our technology:
http://www.asxcaml.org/
http://www.freerp.org/


	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it

Re: [Caml-list] exception Failure and failwith

[Luc Maranget]

> It's what I was afraid of.
> I got it. Anyway let me make a consideration: It would be nice to have a 
> way (a fake module named Core,for example) to access the core types, 
> exception and definitions in case someone shadows the original one.

Why not, but frankly, I am not sure this can be done easily. Besides,
this would potentially break user code, for users who happen to have a
module named 'Core'.


> 
> exception Prim_Failure = Failure
> 
> to get rid of any further shadowing.
Good point which I missed.

As a conclusion, it is clear that the management of the so-called
'built-ins' is somehow unfortunate, and that perhaps, not all built-ins,
need to be so.

However the behavior is properly documented and workarounds are available.




Luc Maranget

Re: [Caml-list] exception Failure and failwith

[sejourne_kevin]

Luc Maranget a écrit :
>>It's what I was afraid of.
>>I got it. Anyway let me make a consideration: It would be nice to have a 
>>way (a fake module named Core,for example) to access the core types, 
>>exception and definitions in case someone shadows the original one.
> 
> 
> Why not, but frankly, I am not sure this can be done easily. Besides,
> this would potentially break user code, for users who happen to have a
> module named 'Core'.
Perhaps a module Pervasives.Core won't have this problem.

	

	
		
___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com

Re: [Caml-list] exception Failure and failwith

[William Lovas]

On Tue, Jun 21, 2005 at 01:34:40PM +0200, Luc Maranget wrote:
> > It's what I was afraid of.
> > I got it. Anyway let me make a consideration: It would be nice to have a 
> > way (a fake module named Core,for example) to access the core types, 
> > exception and definitions in case someone shadows the original one.
> 
> Why not, but frankly, I am not sure this can be done easily. Besides,
> this would potentially break user code, for users who happen to have a
> module named 'Core'.

In fact, one could easily build such a "Core" module as a user, following
Julien's advice:

> > exception Prim_Failure = Failure
> > 
> > to get rid of any further shadowing.

Just take this to the next level with something like:

    module Core =
      struct
        exception Failure = Failure
        type 'a opt = 'a option = None | Some of 'a
        type 'a option = 'a opt
        (* ... *)
      end

(Note the minor contortion: we have to introduce a fake name 'a opt in
order to avoid creating a cyclic type abbreviation, since data type
definitions are automatically recursive.  But of course, you can skip the
second step if you don't care about having a type called 'a Core.option)

While tedious, it's the sort of thing you could add to as you discover new
reasons to do so.  This Core module would allow interactions like the
following situation, which might conceivably arise due to careless
shadowing:

    (* function defined over primitive 'a option *)
    let valOf = function
        | None -> failwith "valOf"
        | Some x -> x;;

    (* evil shadowing *)
    type 'a option = None of 'a | Some of int
    exception Failure of bool;;

    try valOf None with Failure s -> s;;          (* doesn't typecheck *)
    try valOf Core.None with Failure s -> s;;     (* doesn't catch Failure *)
    try valOf Core.None with Core.Failure s -> s;;    (* works! *)

cheers,
William

Re: [Caml-list] exception Failure and failwith

[Luca Pascali]

William Lovas wrote:

>On Tue, Jun 21, 2005 at 01:34:40PM +0200, Luc Maranget wrote:
>  
>
> [...]
>
>In fact, one could easily build such a "Core" module as a user, following
>Julien's advice:
>
>  
>
It's what I did. I added to my project a module named core.
This module just has the redefinition of exceptions

>>>exception Prim_Failure = Failure
>>>
>>>to get rid of any further shadowing.
>>>      
>>>
>
>Just take this to the next level with something like:
>
>    module Core =
>      struct
>        exception Failure = Failure
>        type 'a opt = 'a option = None | Some of 'a
>        type 'a option = 'a opt
>        (* ... *)
>      end
>  
>
[...]

>cheers,
>William
>
>  
>
At the moment, in my module, I put only the exceptions, because they are 
the most critical. (It's easier to use a name like Failure for an 
exception or an enumeration, instead of redefining an option type).
Anyway if I will ever need to redefine built-in enumerations too, I will 
use your method.

Bye
LP

-- 
*********************************************************************
Luca Pascali
luca@barettadeit.com
asxcaml-guru@barettadeit.com

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

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

Our technology:
http://www.asxcaml.org/
http://www.freerp.org/


	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it

Re: [Caml-list] exception Failure and failwith

[Julien Signoles]

> It's all about the failwith function of pervasives (that simply raises
> an exception Failure of string).
> Normally, that exception can be cought by means of a try...with using as
> clause something like
> | Failure s -> .....
>
> But what if I want to catch the Failure exception? :-/
> It seems that no module defines it, so I did not find any way to
> identify the exception.

You're right: no module defines Failure. But you can make an alias for the
primitive Failure and use it:

==========
exception Prim_Failure = Failure
exception Failure
let f () = failwith ""
let () =
  try f (); assert false
  with Prim_Failure _ -> print_endline "primitive failure"
     | Failure        -> print_endline "redefined failure"
==========

Hope this helps,
Julien Signoles
-- 
mailto:Julien.Signoles@lri.fr ; http://www.lri.fr/~signoles
"In theory, practice and theory are the same,
but in practice they are different" (Larry McVoy)