Re: Handling branch cuts for hypergeometric function s

I was only suggesting error codes because an exception handling mechanism
may be too much work. Strictly as a matter of principle, I'm much more in
favor of exceptions than error codes.

So... how would we go about adding exception support to Maxima?


Viktor
 

-----Original Message-----
From: Raymond Toy [mailto:raymond.toy at ericsson] 
Sent: Monday, February 14, 2005 4:09 PM
To: Viktor T. Toth
Cc: maxima@math.utexas.edu
Subject: Re: [Maxima] Re: Handling branch cuts for hypergeometric function s

>>>>> "Viktor" == Viktor T Toth  writes:

    >> Well, I would consider that an error in your program, if it needs
    >> to know the sign of X and doesn't

    Viktor> I think you miss the point here. My program doesn't need
    Viktor> to know the sign of X. It is a subprogram that my program
    Viktor> calls that needs to know the sign of X. In order for my
    Viktor> program to know that it requires knowledge of the sign of
    Viktor> X, it has to possess knowledge of the _internal workings_
    Viktor> of the subprogram, and every other subprogram that that
    Viktor> subprogram calls upon.

    Viktor> In other words, it is one thing to properly respond to
    Viktor> error codes returned by a subroutine, it's another thing
    Viktor> altogether to _predict_ the behavior of the subroutine,
    Viktor> and avoid calling it with parameters that'd trigger
    Viktor> interactive behavior.

I think having maxima (lisp) signal a continuable error solves all of
these issues.  If your program doesn't want to deal with these issues,
it installs a handler so that when such a signal occurs, it handles it
and does whatever it thinks is appropriate.   For everyone else, you
get a query about what to do.  If we wanted to get fancy, we could
even install a default handler to abort if there's no interactive
stream to prompt for the answers.

Returning error codes is a mistake, in my opinion.

Ray