[Feature] Add onerror cb for submit

[hieusmiths]

Current Situation:
We are currently using the onError callback within useStream to handle all errors. However, this approach seems too generic and is primarily suitable for logging purposes rather than robust error handling.

Problem:
The generic error handling is not sufficient for user-facing scenarios where specific error conditions require particular user actions, such as retrying an operation.

Sample Use Case:

• A user submits a request to initiate a stream.
• The stream operation fails.
• The application needs to display a specific error message to the user, along with an option to retry the operation.

[changeset-bot]

⚠️ No Changeset found

Latest commit: aa52219

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[dqbd]

Hello! I think it might make more sense to handle the exceptions in a try / catch instead, will check the types!

[hieusmiths]

Hello! I think it might make more sense to handle the exceptions in a try / catch instead, will check the types!

Yes, using try-catch on a submit Promise would be good. Unfortunately, client.runs.stream is designed for callbacks, and all its behavior is already within try-catch blocks without re-throwing, so we can't implement that here.

[hieusmiths]

Hello! I think it might make more sense to handle the exceptions in a try / catch instead, will check the types!

Yes, using try-catch on a submit Promise would be good. Unfortunately, client.runs.stream is designed for callbacks, and all its behavior is already within try-catch blocks without re-throwing, so we can't implement that here.

Hi @dqbd Could you help this one?