[asterisk-dev] application errors

[Moises Silva]

I don't see any problem with returning 0 and setting FAXSTATUS. I have
not checked for other applications *ALWAYS* returning 0. However I
don't think it matters that much. If sending a fax fails, it is
understandable that people want to do something else in the dial plan,
so aborting dial plan execution is not the way to go. Set FAXSTATUS
and move on :)

As I understand returning -1 is reserved for calling the application
without the proper arguments or stuff like that. Note that Asterisk
parser does not check for applications being called with the proper
arguments (given arguments complexity), so, checking inside and
returning -1 is the way we have to indicate a flawed dial plan.

Regards,

Moy

On 10/29/07, Dmitry Andrianov <dimas at dataart.com> wrote:
>
>
>
>
> Hello.
>
> I tried asking on IRC but it looks like nobody was available at the moment.
>
> Need an advice or something regarding the issue 10815 - SendFAX/ReceiveFAX
> applications. Much like as their ancestors (txfax/rxfax), these applications
> return -1 in case of any problem with the channel. As I understand negative
> result immediately aborts dialplan execution. However, people are asking to
> add FAXSTATUS channel variable set by the application which will indicate if
> transmission was successful or not. But again, in case of any error,
> application returns -1 so there is no sense in setting any variable because
> no one will be able to review it.
>
> At the same time I understand people who may want to know if fax was sent or
> not. The only way to satisfy them I see is to ALWAYS return zero from the
> application to let dialplan execute (and setting FAXSTATUS with something
> indicating error). The problem is that I haven't seen any application in the
> Asterisk which returns zero always - even in the case of channel hangup etc,
> reporting failures by means of channel variables. So creation of such
> application can be considered a bad practice.
>
>
>
> So the question is - what is the best (or recommended) approach here?
>
>
>
> Thanks.
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>


-- 
"Within C++, there is a much smaller and cleaner language struggling
to get out."