Skip to content

fix: Export application error prompt repeated #1945

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
shaohuzhang1 merged 1 commit into from
Dec 30, 2024
Merged

fix: Export application error prompt repeated #1945

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 5 additions & 3 deletions ui/src/views/application/index.vue
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -226,9 +226,11 @@ function settingApplication(row: any) {
}
const exportApplication = (application: any) => {
applicationApi.exportApplication(application.id, application.name, loading).catch((e) => {
e.response.data.text().then((res: string) => {
MsgError(`导出失败:${JSON.parse(res).message}`)
})
if (e.response.status !== 403) {
e.response.data.text().then((res: string) => {
MsgError(`导出失败:${JSON.parse(res).message}`)
})
}
})
}
const importApplication = (file: any) => {
Copy link
Contributor Author

@shaohuzhang1 shaohuzhang1 Dec 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Missing Handling for Status Code 403: The current implementation includes an if statement that only handles status codes other than 403. However, it's essential to handle status code 403 specifically because it means there's a permission issue with exporting the application.

  2. Handling Other Error Codes: While your implementation already catches all types of errors under e.response, you might want to add specific handling for other error statuses like 500 (Server Internal Error), 404 (Not Found), etc., based on your application requirements.

  3. Refactoring Comments and Variables: You could refactor some comments and variable names for clarity:

const exportApplication = async (application: any) => { // Use async/await for cleaner error handling
  try {
    await applicationApi.exportApplication(application.id, application.name);
  } catch (err) {
    if (err.response && err.response.status === 403) {
      MsgError('Permission denied to export application');
    } else {
      MsgError(`Export failed: ${JSON.stringify(err.response ? err.response.data : 'Unknown error')}`);
    }
  }
};

// Similar pattern can be applied to importApplication function

  1. Consider Using Axios Interceptors: If applicationApi.exportApplication is using Axios, you can also use Axios interceptors to globally handle responses such as logging errors, retrying requests, or updating UI states without having multiple instances of catching and responding to errors in each API call.

  2. Ensure Consistent Response Formatting: Always ensure that when sending errors back from the server, they include consistent metadata such as status code and message format so that clients expect a standardized response.

These modifications should improve robustness and readability of your code while addressing potential issues related to user permissions, general error management, and possibly integration with other APIs or libraries.

Expand Down