Salve, here is a proposal for future improval of the ser.cfg language: exceptions.
Currently, we have some cases where functions magically create an error
response all by itself: save_contacts() is one, some of the functions in
tm are others. The result is that you sometimes get an error response
back and have no idea where it came from. The only way to figure out
that a 503 in response to a REGISTER means that you have hit max_contacts
is to study the source of the registrar module.
Alternatively, we have mysterious return values. An example of that are
the functions from the auth_* modules. You have to know what -2 or so
means if you want to create the right response.
I believe, a clean, general, and re-usable mechanism for this would be
quite a good idea. Exceptions, or rather something modelled loosely on
the concept of exceptions in other languages, is my take on it.
Whenever the internal implementation of script function wants to flag a
fatal error, it currently can choose between returning a value less than
zero, indicating a return value of false in the script and continued
execution, or 0, indicating that script processing should be stopped.
This in itself is somewhat twisted. In C, boolean false is usually 0 and
a fatal error is -1. In the script these two are thus meshed into one. A
return value of false can mean both a negative answer, eg., in
attr_exists(), or an error in processing, eg., in save_contacts().
The reaction in the latter case is almost exclusively to return an error
response which in most cases can happen all by itself. Meaning that
whenever it encounters a fatal error, the script function returns an
error response and never returns. A return value of false thus always
means a negative answer.
Now, to allow the user to influence what really happens, the module
function doesn't really send a response all by itself. Instead it sets
an internal variable (some sort of errno) to the name of an exception
and starts exception handling.
There are two options how to handle the exception. By default, a
response is sent back with pre-defined status code and reason phrase.
Both can be changed in the configuration for each exception.
Alternatively, you can register a route for each exception and do
whatever you want. This can either be done globally in the parameter
section or temporarily by a call from the script.
We may even introduce a raise() function where you can raise a certain
exception.
This whole thing has one more advantage: It clears the way to allow
different types of return values for script functions and nice
constructions such as
$tu.uid = lookup_user("@ruri");
because we don't need the return value for error reports anymore.
Best regards,
Martin
signature.asc
Description: Digital signature
_______________________________________________ Serdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/serdev
