Andrei Pelinescu-Onciul wrote:
> On Jul 02, 2008 at 13:53, Martin Hoffmann <[EMAIL PROTECTED]> wrote:
> >
> > 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?
In most cases you wouldn't care. In the same way as most programmers
don't catch exceptions either. You just need to remember that they are
for real errors only and not for conveying some information back to the
caller.
In the cases where it should matter, I'd rather have the mechanism to
locally register a route as a handler and save a new script language
construct.
We could possibly add a feature that exceptions can have variables. I
would limit this, though, simply to an alternative reason phrase.
> > 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?
As long as these are strings, it doesn't really matter. Also, allow
modules to define their own exceptions much in the same way as they
already define functions and selects.
> > 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.
Sure.
Let's stick to save_contacts() returning 503 when you try to register
more then max_contacts contacts. The registrar module would internally
define the exception, say, MaxContactsError with a default status of
503 and the default reason "Too Many Contacts". If you don't do anything
in your script, SER will stop processing and return a response with the
default status and reason (somehow tm needs the chance to send the
response statefully if a transaction has already been started).
If you only want a different status code or reason phrase, for instance
because your service is in German, you put, say,
exception MaxContactsError reply(503, "Zu viele Kontaktadressen")
somewhere at the top of your ser.cfg. If you want to do something fancy,
you do
exception MaxContactsError route(MaxContactsError)
and later define
route[MaxContactsError]
{
# Do your thing
}
Alternatively, you could also register the route inside the routing
logic:
route[REGISTRAR]
{
# ...
exception MaxContactsError route(MaxContactsError);
$contacts = save_contacts("location");
append_to_reply($contacts);
sl_reply(200);
drop;
}
(This includes a change we should probably do to registrar to make it
work like the auth stuff.)
If we define some generic exceptions such as Error403 or Error404 and
define a raise() function, you can simplify the script quite a bit. A
random pick from ser-oob:
route[DOMAIN_POLICY]
{
if (!isflagset(FLAG_TOTAG) && !$t.did && !$f.did) {
raise(Error403);
}
}
Or, with the option to change the reason phrase:
route[DOMAIN_POLICY]
{
if (!isflagset(FLAG_TOTAG) && !$t.did && !$f.did) {
raise(Error403, "Relaying Forbidden");
}
}
To me, this looks better than the sl_reply()/drop pairs. The current
ser.cfg style is somewhat contrary to what programming classes preach.
> 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.
Looking forward to it.
Regards,
Martin
_______________________________________________
Serdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/serdev
