From: sejourne_kevin <sejourne_kevin@yahoo.fr>
To: caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] Re: OCAML Downcasting?
Date: Wed, 22 Sep 2004 11:03:45 +0200 [thread overview]
Message-ID: <41513FF1.3090402@yahoo.fr> (raw)
In-Reply-To: <87d60eizlh.fsf@qrnik.zagroda>
Marcin 'Qrczak' Kowalczyk wrote:
> skaller <skaller@users.sourceforge.net> writes:
>
>
>>>Attempts to avoid downcasts are often unmodular, they require to
>>>specify all possible variants in one place.
>>
>>It makes no difference. You have do specify them all anyhow,
>>downcast or not.
>
>
> It makes a difference because specifying them at the type definition
> would introduce a dependency loop between modules. And it would be
> unmodular: it would require changing some base module whenever a far
> client module is added.
>
> Apply this reasoning to the exn type. Why don't you define all exn
> constructors in one place?
I think there is no problems with exceptions. But if you have problems
managing exceptions in large modules have you try something like this ?
here an example:
I define all my exceptions like this :
let errors = ref [];;
(*to define an error*)
(*errors "the exception" , the new value*)
errors := ("div by zero" ,0) :: (!errors);;
And the functions catch errors in this way:
let truc () =
try
...
with
... all Ocaml pre-defined exceptions
| exn -> (* my exceptions in errors list ref *)
let s = Printexc.to_string exn in
... Lex & Parse 's' in (fst errors) ref list , then handle error ...
;;
If exceptions are complex I can use polymorphic variants
for the "new value".
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
next prev parent reply other threads:[~2004-09-22 10:00 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ci7tcf$qqf$1@wolfberry.srv.cs.cmu.edu>
[not found] ` <ci9ggm$i6p$1@wolfberry.srv.cs.cmu.edu>
2004-09-21 8:03 ` Jacques GARRIGUE
2004-09-21 8:43 ` Damien Pous
2004-09-21 9:15 ` Jacques GARRIGUE
2004-09-21 9:29 ` skaller
2004-09-21 9:49 ` Jacques GARRIGUE
2004-09-21 9:34 ` Stefano Zacchiroli
2004-09-21 9:56 ` Jacques GARRIGUE
2004-09-21 19:27 ` Michael Vanier
2004-09-21 21:38 ` Brian Hurt
2004-09-21 22:06 ` Michael Vanier
2004-09-21 22:32 ` Brian Hurt
2004-09-22 1:04 ` skaller
2004-09-21 22:20 ` Marcin 'Qrczak' Kowalczyk
2004-09-22 2:26 ` skaller
2004-09-22 6:31 ` Marcin 'Qrczak' Kowalczyk
2004-09-22 9:03 ` sejourne_kevin [this message]
2004-09-22 10:29 ` Richard Jones
2004-09-22 18:39 ` Brian Hurt
2004-09-22 10:50 ` skaller
2004-09-22 12:03 ` Alain Frisch
2004-09-22 12:50 ` Cláudio Valente
2004-09-22 13:15 ` Marcin 'Qrczak' Kowalczyk
2004-09-22 15:50 ` skaller
2004-09-22 18:42 ` Brian Hurt
2004-09-22 18:44 ` Marcin 'Qrczak' Kowalczyk
2004-09-22 19:18 ` Brian Hurt
2004-09-22 0:50 ` skaller
2004-09-22 1:30 ` Jacques GARRIGUE
2004-09-22 2:59 ` skaller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41513FF1.3090402@yahoo.fr \
--to=sejourne_kevin@yahoo.fr \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox