On Jul 02, 2008 at 13:53, Martin Hoffmann <[EMAIL PROTECTED]> wrote:
> 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.
I agree, something similar to exceptions would be a good idea.
>
[...]
>
> 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.
But then how would you know which function generated the exception?
Have try{} blocks around each function?
e.g.: try { t_relay() } catch * { ... } ?
>
> 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.
But this would mean defining a very large set of possible exceptions,
wouldn't it?
>
> 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");
We definitely should have those.
Could you come up with some script examples? I think examples would
show possible problems and advantages better.
As a matter of fact I'm about to start another thread about future
changes in the script language/engine, avp , vars a.s.o. It's main
purpose is to collect proposals and especially script examples for what
people would want to have. Once we have enough we can start thinking
about the next gen script (IMO the script engine should be re-written
anyway and it would help if we come up with some kind of a requirement
list before this happens).
We can move the discussion to this new thread.
Andrei
_______________________________________________
Serdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/serdev
