class IntegrationError
Custom exception class that signals failures in external integrations within the CDocs controller system.
/tf/active/vicechatdev/CDocs/controllers/__init__.py
80 - 82
simple
Purpose
IntegrationError is a specialized exception class that inherits from ControllerError. It is designed to be raised when operations involving external integrations (such as third-party APIs, external services, or system integrations) fail. This allows for specific error handling and logging of integration-related failures, distinguishing them from other types of controller errors in the CDocs application. By using this exception, developers can catch and handle integration failures separately from other error types, enabling more granular error recovery strategies and better error reporting.
Source Code
class IntegrationError(ControllerError):
"""Exception raised when an external integration fails."""
pass
Parameters
| Name | Type | Default | Kind |
|---|---|---|---|
bases |
ControllerError | - |
Parameter Details
*args: Variable length argument list passed to the parent Exception class. Typically includes the error message as the first argument, followed by any additional context information.
**kwargs: Arbitrary keyword arguments passed to the parent Exception class. Can include additional metadata about the error.
Return Value
Instantiation returns an IntegrationError exception object that can be raised. When raised, it propagates up the call stack until caught by an exception handler. The exception object contains the message and any additional arguments passed during instantiation, accessible via the args attribute inherited from BaseException.
Class Interface
Methods
__init__(*args, **kwargs)
Purpose: Initializes the IntegrationError exception instance with error message and optional context
Parameters:
*args: Variable arguments, typically starting with an error message string, followed by any additional context**kwargs: Keyword arguments for additional metadata
Returns: None (constructor)
__str__() -> str
Purpose: Returns string representation of the exception (inherited from BaseException)
Returns: String representation of the exception, typically the error message
__repr__() -> str
Purpose: Returns detailed string representation of the exception (inherited from BaseException)
Returns: Detailed string representation including class name and arguments
Attributes
| Name | Type | Description | Scope |
|---|---|---|---|
args |
tuple | Tuple of arguments passed to the exception constructor, inherited from BaseException. Typically contains the error message and additional context. | instance |
__cause__ |
Optional[BaseException] | The exception that was the direct cause of this exception, set when using 'raise ... from' syntax | instance |
__context__ |
Optional[BaseException] | The exception context, automatically set when an exception is raised during handling of another exception | instance |
Required Imports
from CDocs.controllers.errors import IntegrationError
from CDocs.controllers.errors import ControllerError
Usage Example
# Raising the exception
try:
# Attempt to call external API
response = external_api.call()
if not response.success:
raise IntegrationError("Failed to connect to external API", response.error_code)
except IntegrationError as e:
logging.error(f"Integration failed: {e}")
# Handle integration failure gracefully
fallback_handler()
# With custom message and context
try:
filecloud_controller.sync_documents()
except Exception as e:
raise IntegrationError(f"FileCloud integration failed: {str(e)}") from e
# Catching specific integration errors
try:
document_controller.export_to_external_system(doc_id)
except IntegrationError:
# Handle integration-specific errors
notify_admin("External system integration is down")
except ControllerError:
# Handle other controller errors
log_general_error()
Best Practices
- Always provide a descriptive error message when raising IntegrationError to help with debugging and logging
- Use IntegrationError specifically for external integration failures, not for internal application errors
- Consider using exception chaining (raise ... from e) to preserve the original exception context when wrapping lower-level exceptions
- Catch IntegrationError at appropriate levels in your application to implement retry logic or fallback mechanisms for external service failures
- Log IntegrationError exceptions with sufficient context to diagnose integration issues, including service names, endpoints, and error codes
- Document which external integrations can raise this exception in your API documentation
- Consider implementing exponential backoff or circuit breaker patterns when catching IntegrationError for resilient integration handling
Similar Components
AI-powered semantic similarity - components with related functionality:
-
class ControllerError 68.0% similar
-
class FileCloudError 67.7% similar
-
class PermissionError_v1 61.5% similar
-
class PermissionError 61.2% similar
-
class ValidationError_v1 60.9% similar