Uploaded image for project: 'CiviCRM'
  1. CiviCRM
  2. CRM-841

Make it possible to install a "fatal" handler for user framework code.


    • Type: Improvement
    • Status: Done/Fixed
    • Priority: Major
    • Resolution: Fixed/Completed
    • Affects Version/s: 1.4
    • Fix Version/s: 1.5
    • Component/s: None
    • Labels:


      I've run into a serious problem writing an XMLRPC handler that calls into CRM 1.4.

      If permissions are insuffient in some of the Group API calls, CRM calls CRM_Core_Error::fatal(). This has several very bad effects:

      1) Since fatal() calls exit(), it's essentially impossible to trap.
      2) Fatal assumes it is running inside web code, and calls "print". So if you are in a context like XMLRPC, you are basically f**ked, since your XMLRPC server will never return an error. (worse: it will return invalid XML and hork your parser).
      3) fatal() does not give the user framework (i.e., Drupal or Mambo) the opportunity to log the error.
      4) in some cases, the user framework can reasonably recover from the error. In this case, it can simply report that the user lacks permissions however the framework likes to to this.

      This is a serious problem for me, since it is simply impossible to write a reliable XMLRPC handler until this is fixed.

      Here's my suggestion:

      1) Add a method to CRM_Core_Error that makes it possible to install a "fatal" handler. The handler will get the same parameters as fatal() does.

      2) If fatal is called and a handler is installed, fatal() will call it and check the return value. It could return one of several codes:

      a) if 0 or FALSE, the handler has done whatever it could do, but still wants CRM to handle the exit. (this would be a good way to allow logging fatal errors).
      b) if CRM_FATAL_ERROR_HANDLED, CRM should assume that any UI has been taken care of, and not to do more. So it exits.
      c) in principle, we could allow the the framework to try and recover from the error, but given how fatal() calls are sprinkled throughout the source, I think this is not feasible without serious changes in the CRM source.

      This is easy to do, and I will supply a patch if the CRM folks are willing to consider it for 1.4.




            • Assignee:
              lobo Donald A. Lobo
              torenware Rob Thorne
            • Votes:
              0 Vote for this issue
              0 Start watching this issue


              • Created: