New APIs for new exception handling?

[Raimo Niskanen]

We will have to contemplate about that. Wrapper modules is a thought,
or alternative functions in the modules with some short and 
informative prefix/suffix, which should be needed for naming
wrapper modules as well.

I think I like wrapper modules. E.g file_t:open/2. Or 'File':open/2,
I hope anyone else has got a better ideas.

Anyway, first we will have to wait and see if the demand surfaces
for real and how strong it becomes.



vances@REDACTED (Vance Shipley) writes:

> Having reviewed the paper on the new exception handling in R10
> I am left wondering how things will change with it's availability.
> 
> My application behaviour modules often have blocks of sequential
> initialization which will benefit from the whole try...of...catch
> ...after...end.  So I can see that try will make it into new code
> right away and I can see it getting quite a bit of use.
> 
> What I wonder about is how we'll deal with existing APIs which 
> return tagged tuples like the start functions of gen_fsm, gen_server
> and supervisor and the gen_tcp and gen_udp modules.  After a point
> it will seem somewhat awkward to be dealing with {ok,Value}/{error,Reason}
> tuples.  It was never too clear to me which form was the one to use in
> my own APIs.  I like the out of band exception handling so returning
> a raw value or exiting has been the rule of thumb however when working 
> with OTP a tagged tuple is required for the return of init functions.
> This requirement would bleed into other functions as using them as the
> tail of the init function was natural.
> 
> Will we see the introduction of a paralell choice to many of these
> functions which uses the pure out of band exception handling? 
> 
> 	-Vance
> 

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB