Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
C
Core
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 930
    • Issues 930
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Incidents
  • Analytics
    • Analytics
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
  • Development
  • Core
  • Issues
  • #833

Closed
Open
Opened Mar 28, 2019 by totten@tottenOwner

(DX) Make backtraces for API exceptions useful

The current API architecture began with this calling convention for checking errors:

$result = civicrm_api(...);
if ($result['is_error']) ...

It quickly became a common problem that callers forgot to check the result for success/failure, so a thin wrapper was introduced which generated an exception instead of returning an error-value:

try {
  $result = civicrm_api3(...);
}
catch (API_Exception $e) {...}

This generally surfaces errors better, but then the next step is: what caused the error? How do I get a backtrace?

The backtrace always points to the wrapper function. If you want the real backtrace, you need to switch back to civicrm_api(), set debug=1, and inspect the output for trace info.

I don't have a quick solution. Questions to elicit thoughts/planning:

  • Can one generate a synthetic exception?
  • If the initial problem is reported as an exception, and if the error is reported to the consumer as an exception, is there some way to pass that along?
  • What are the implications for an existing consumer which uses civicrm_api3() and looks for API_Exception?
  • What are the implications for an existing consumer which uses civicrm_api() and looks for a trace?
  • How does this fit into the lifecycle of API kernel (e.g. of events/listeners using civi.api.exception)?
Edited Mar 28, 2019 by totten
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: dev/core#833