Comparing Error Responses: Which One Aids Debugging Better?
Suppose we have executed an HTTP request using CAP and it fails. Below are two logged error responses:
1st Scenario:
2nd Scenario:
It’s immediately clear which version is easier to debug and helps us quickly identify the reason for the failure.
When building SAP extensions or integrations, developers often rely on Axios for handling HTTP requests. While Axios simplifies API communication, error handling can quickly become a challenge—especially when debugging complex integration scenarios.
In many projects, errors are either logged with too little detail (just a generic message) or with too much raw data, making debugging time-consuming. To improve maintainability and speed up root cause analysis, we need a structured error logging mechanism.
Why Structured Error Logging Matters
In enterprise scenarios like SAP SuccessFactors or SAP BTP service integrations, requests often involve multiple systems. Without detailed error insights, you might only see:
Error: Request failed with status code 400
But what you really need is:
Which endpoint failed?
What payload was sent?
What was the response from the server?
Was there any custom error code attached?
This is where a structured error handling approach becomes invaluable.
Implementation: A Structured Axios Error Logger
Here’s a reusable utility function you can plug into your Node.js / TypeScript projects:
public getAxiosErrorObject(error: any) {
if (error.isAxiosError) {
const errorObj = {
message: error.message || ‘An error occurred during the request.’,
code: error.code || ‘UNKNOWN’,
status: error.response ? error.response.status : ‘No Status’,
statusText: error.response ? error.response.statusText : ‘No Status Text’,
requestData: error.config ? error.config.data : ‘No Request Data’,
requestMethod: error.config ? error.config.method : ‘No Request Method’,
requestUrl: error.config ? error.config.url : ‘No Request URL’,
responseData: error.response ? error.response.data : ‘No Response Data’
};
return errorObj;
}
return {
message: error.message || ‘An unknown error occurred’,
stack: error.stack || ‘No Stack Trace’
};
}
How It Works
Checks if it’s an Axios error
Axios sets error.isAxiosError = true. This allows us to distinguish between HTTP request errors and other runtime issues.
Captures request details
The request URL, method, and payload are logged, which is crucial for reproducing and debugging issues.
Captures response details
If the server responded, we extract the status code, status text, and response body.
Fallback for non-Axios errors
In cases where the error didn’t come from Axios (e.g., runtime exceptions), we still log a meaningful message and stack trace.
Example Usage
try {
const response = await axios.post(‘/api/employees’, { name: ‘Sahil M’ });
console.log(response.data);
} catch (error) {
const structuredError = this.getAxiosErrorObject(error);
console.error(‘API Error:’, structuredError);
}
Example Output
{
“message”: “Request failed with status code 400”,
“code”: “ERR_BAD_REQUEST”,
“status”: 400,
“statusText”: “Bad Request”,
“requestData”: “{“name”:”Sahil M”}”,
“requestMethod”: “post”,
“requestUrl”: “/api/employees”,
“responseData”: {
“error”: “Invalid employee data”
}
}
Best Practices
Avoid logging sensitive data
When logging request payloads, ensure no confidential fields (e.g., passwords, tokens) are exposed.
Integrate with monitoring tools
Forward structured error logs to tools like SAP Cloud Logging for central monitoring.
Normalize error structure
Use this function as a single source of truth for error logging across your project, ensuring consistent logs.
Enhance with correlation IDs
In SAP integrations, add transaction or correlation IDs to quickly trace requests across systems.
Comparing Error Responses: Which One Aids Debugging Better?Suppose we have executed an HTTP request using CAP and it fails. Below are two logged error responses:1st Scenario:2nd Scenario:It’s immediately clear which version is easier to debug and helps us quickly identify the reason for the failure.When building SAP extensions or integrations, developers often rely on Axios for handling HTTP requests. While Axios simplifies API communication, error handling can quickly become a challenge—especially when debugging complex integration scenarios.In many projects, errors are either logged with too little detail (just a generic message) or with too much raw data, making debugging time-consuming. To improve maintainability and speed up root cause analysis, we need a structured error logging mechanism.Why Structured Error Logging MattersIn enterprise scenarios like SAP SuccessFactors or SAP BTP service integrations, requests often involve multiple systems. Without detailed error insights, you might only see:Error: Request failed with status code 400 But what you really need is:Which endpoint failed?What payload was sent?What was the response from the server?Was there any custom error code attached?This is where a structured error handling approach becomes invaluable.Implementation: A Structured Axios Error LoggerHere’s a reusable utility function you can plug into your Node.js / TypeScript projects:public getAxiosErrorObject(error: any) {
if (error.isAxiosError) {
const errorObj = {
message: error.message || ‘An error occurred during the request.’,
code: error.code || ‘UNKNOWN’,
status: error.response ? error.response.status : ‘No Status’,
statusText: error.response ? error.response.statusText : ‘No Status Text’,
requestData: error.config ? error.config.data : ‘No Request Data’,
requestMethod: error.config ? error.config.method : ‘No Request Method’,
requestUrl: error.config ? error.config.url : ‘No Request URL’,
responseData: error.response ? error.response.data : ‘No Response Data’
};
return errorObj;
}
return {
message: error.message || ‘An unknown error occurred’,
stack: error.stack || ‘No Stack Trace’
};
} How It WorksChecks if it’s an Axios errorAxios sets error.isAxiosError = true. This allows us to distinguish between HTTP request errors and other runtime issues.Captures request detailsThe request URL, method, and payload are logged, which is crucial for reproducing and debugging issues.Captures response detailsIf the server responded, we extract the status code, status text, and response body.Fallback for non-Axios errorsIn cases where the error didn’t come from Axios (e.g., runtime exceptions), we still log a meaningful message and stack trace.Example Usagetry {
const response = await axios.post(‘/api/employees’, { name: ‘Sahil M’ });
console.log(response.data);
} catch (error) {
const structuredError = this.getAxiosErrorObject(error);
console.error(‘API Error:’, structuredError);
}Example Output {
“message”: “Request failed with status code 400”,
“code”: “ERR_BAD_REQUEST”,
“status”: 400,
“statusText”: “Bad Request”,
“requestData”: “{“name”:”Sahil M”}”,
“requestMethod”: “post”,
“requestUrl”: “/api/employees”,
“responseData”: {
“error”: “Invalid employee data”
}
}Best PracticesAvoid logging sensitive dataWhen logging request payloads, ensure no confidential fields (e.g., passwords, tokens) are exposed.Integrate with monitoring toolsForward structured error logs to tools like SAP Cloud Logging for central monitoring.Normalize error structureUse this function as a single source of truth for error logging across your project, ensuring consistent logs.Enhance with correlation IDsIn SAP integrations, add transaction or correlation IDs to quickly trace requests across systems. Read More Technology Blog Posts by SAP articles
#SAP
#SAPTechnologyblog
