[asterisk-users] Including doesn't have any effect

Steve Edwards asterisk.org at sedwards.com
Mon Jun 6 10:08:44 CDT 2016

On Mon, 6 Jun 2016, Frank Vanoni wrote:

> On Sat, 2016-06-04 at 15:19 -0700, Steve Edwards wrote:
>> Using a 'goto' to exit from a gosub is a bad idea.
> Why?

The purpose of a subroutine (code that is entered by a gosub and exited by 
a return) is to allow the creation of easily reusable code. It 'packages' 
complex or frequently used code into a nice little black box. You don't 
need to know all the details of what happens in the box and you can use 
this little box throughout your code without having to tell it where to 
continue when it has finished -- it just 'knows' by virtue of it's 

A 'gosub' is implemented (in most languages) by pushing the address of the 
instruction following the gosub onto the stack. When the return is 
executed, this address is popped off the stack and loaded into the program 

Using a 'goto' to exit from a subroutine does not 'pop' off the return 
address. If this cycle of pushing addresses and not popping off addresses 
is repeated enough, you may run out of stack space.

Think how complex and difficult to maintain your dialplan would be if you 
had to tell each application (dial(), playback(), set(), etc) where to go 
when it was finished. Even worse, imagine if each application had a fixed 
"I'm finished" address (priority or label).

Most programmers consider 'goto' to be 'evil' because it allows 
(encourages?) lazy design leading to difficult to maintain/reuse code. 
(Google 'why is goto bad'.) Some languages do not even include a 'goto' by 
design to encourage programmers to write better code.

>> A better idea would be to set a channel variable and check it's value 
>> after the return, in the calling context.
> The idea is to update the blacklist.conf whenever I want to add or 
> remove a specific number or an entire area code and leave the 
> extensions.conf untouched and to avoid complex regular expressions.

The idea is fine. The implementation is flawed.

It should be implemented as a subroutine (or AGI) and return the success 
or failure as a channel variable. This will result in an 'easier to 
comprehend' and more maintainable dialplan.

This 'design pattern' (a subroutine) would allow you to reuse this same 
'black box' in other parts of your dialplan.

Think of 'the next guy' -- which may be you in a couple of months when the 
'finer details' of your implementation fade. If you jump all around your 
dialplan it gets very hard to comprehend. If you can see that you execute 
a little black box and then do something based on an intuitively named 
channel variable the design and intent is obvious.

> Well... I'm not an expert and my approach is by "trial and error". It 
> works perfectly. :-)

A 'better' approach is to learn from the mistakes of others.

I suspect it 'works perfectly' until it's been running long enough to 
cause difficult to diagnose problems.

Thanks in advance,
Steve Edwards       sedwards at sedwards.com      Voice: +1-760-468-3867 PST

More information about the asterisk-users mailing list