Re: [Caml-list] Uncaught exceptions in function type.

["Daniel Bünzli" <daniel.buenzli@erratique.ch>]

Le mardi, 27 mai 2014 à 08:52, Philippe Veber a écrit :

> - I observed in many libraries (including Xmlm) that people tend to define custom exceptions to signal parsing errors. According to the rules you provide, parsers should return variants, right?

Yes, I was unexeperienced.  Also I didn’t understand that the world was asynchronous at that time. See jsonm for a more sensitive interface.

> - as Ben noted earlier, I think point 2 would better be formulated as errors that can virtually appear anywhere and/or a programmer cannot do much about (as you say)
> - The adjective "exceptional" is a bit misleading IMO, in particular I guess it should not be understood as "not frequent". Rare failures can be very harmful and should be given extra-care since they are not easy to provoke and debug. Did you mean more like "very abnormal" and so difficult to recover?

Well all what you mention seems exceptional to me (at least I wouldn’t like to work with an API that allows errors to virtually happen everywhere on a regular basis)… But feel free to call that differently.  
  
> - Another criterion I like is that if checking the precondition of a function f basically amounts (in terms of complexity/algorithm) to calling f, then f shouldn't raise an exception for this precondition. If the precondition is difficult to check, a user is likely not to check it:
> - List.find assumes the searched element is in the list, but checking that is precisely what the function is about.

Yes, note that finding things in datastructures is pretty clear API wise. Usually there are two cases 1) the programmer doesn’t if the item is in the datastructure 2) the programmer knows it’s in there and doesn’t want to be annoyed. This leads to

1) val find : t -> key -> value option
2) val get : t -> key -> value (and raises Invalid_argument if the thing is not in there).  
  
> Having no experience on large projects, it is not clear to me why exceptions are considered so dangerous.  

If you don’t/forget to catch the exception at the right place it disrupts your whole call stack, which means that it breaks any invariants a correct excecution of your call stack was supposed to maintain. Which means that your program state is completely broken and you have to exit 1, hoping that you didn’t partially (invariant wise) persist anything to disk/network meanwhile.

Best,

Daniel