#20 ✓hold
Jay Phillips

Dialplans with syntax error should report errors in the console output

Reported by Jay Phillips | February 19th, 2008 @ 08:39 PM

This problem has to do with the DialPlan builder which instance_evals the code read from the dial plan. It definitely raises a SyntaxError there but for some reason the exception doesn't make it up to the AGI server.

Comments and changes to this ticket

  • Jay Phillips

    Jay Phillips February 19th, 2008 @ 08:44 PM

    • State changed from “new” to “open”
    • Title changed from “Dialplans with syntax error report errors in the console output” to “Dialplans with syntax error should report errors in the console output”
  • Jay Phillips

    Jay Phillips March 6th, 2008 @ 09:47 PM

    For the record, I took a look into this recently and there is some WEIRD shit going on that's gobbling up that SyntaxError. No resolution yet...

  • Jay Phillips

    Jay Phillips March 24th, 2009 @ 06:41 PM

    • Milestone cleared.
    • Tag set to dialplan
  • Ben Klang

    Ben Klang June 28th, 2010 @ 03:36 PM

    • Assigned user cleared.
    • Milestone set to 0.8.5
    • Milestone order changed from “0” to “0”
  • Ben Klang

    Ben Klang July 28th, 2010 @ 10:41 PM

    • Tag changed from dialplan to lost exceptions, dialplan
  • Ben Klang

    Ben Klang July 29th, 2010 @ 11:38 PM

    • Assigned user set to “Ben Klang”
    • State changed from “open” to “hold”
    • Milestone cleared.

    After researching the issue, I can at least explain the cause. The default behavior for unhandled exceptions that occur within threads is for the thread to terminate. However, the rest of the application does not. This can mean that exceptions are silently lost.

    Some documentation on the issue here:
    http://engineroom.mixx.com/2008/07/31/when-rescue-doesnt/
    and here (search for "Threads and Exceptions"):
    http://ruby-doc.org/docs/ProgrammingRuby/html/tut_threads.html/

    One workaround would be to enable Thread.abort_on_exception within Adhearsion itself. For my development purposes, this is exactly what I will do. The downside to this approach is that any unhandled exception within Adhearsions internals can cause the entire application to exit. In my testing, I have already identified several places where this was happening (harmlessly) but the exceptions were never visible.

    I propose NOT to change this setting in Adhearsion itself until we have had time to run through more tests and ensure that the application does not throw any internal unhandled exceptions. When we are satisfied that Adhearsion is internally stable, we can enable the Thread.abort_on_exception to allow end-users to be able to debug their applications more easily.

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Shared Ticket Bins

People watching this ticket

Pages