Feat/enhance fixed rate scheduling and block data listener#390
Conversation
…ror handling and logging - add logging capabilities for task execution and exception handling - introduce catchExceptions parameter to control exception behavior - update runAtFixedRate and runWithFixedDelay functions to support new logging features - add runUntil function for conditional execution with error handling
twisti-dev
deleted the
feat/enhance-fixed-rate-scheduling-and-block-data-listener
branch
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8026083d1d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (catchExceptions) { | ||
| logging.logger.error("Exception in ${logging.name}", throwable) |
There was a problem hiding this comment.
When catchExceptions is true (now the default), the scheduler catch blocks pass every Throwable here, so a task that throws a JVM Error such as OutOfMemoryError or LinkageError is only logged and the loop continues. Those are not recoverable task exceptions; swallowing them can leave the process running in a corrupted state instead of letting the coroutine fail. Please limit the caught type to ordinary exceptions or rethrow Error even when exception catching is enabled.
Useful? React with 👍 / 👎.
1 participant
No description provided.