Thank you for your reply, Jamie!
It's best to use the standard TRY, Raise, Exception , Finally etc..
Well, try... except... finally will be job of a user of the library; as an author of it I will use only Raise if
I opt for exceptions mechanism.
Most coders assumes any function that receives parameters from a dynamic/Dereference
value that may cause an issue, like divide by 0 for example, is usually encapsulated with a Try and except
statement to catch possible Raise exceptions in functions, for example, a math function you may create and
force it to fault.
There are times where a complex return type maybe required and thus employment of a record is needed.
In such cases, you can have a Boolean in there to indicate pass or failure.
So, your point of view is that exception is not a best mechanism for situation when an error is generated due to
invalid user-supplied values, right?
Mechanism with the return of boolean as an error or success flag I do not like very much, because in many cases
it is convenient to return a result result of computations and, as Leledumbo rightly points out, error handling must
be uniform throughout the library.
Btw, Is the Math unit insufficient for your needs?
Yes
I nice DFT and IDFT , FFT would be nice as a stand alone LIB
Well, signal processing. For now, in his field I have non-visual components for
gaussian, moving average and median filters.