power-policy-service: Depanic#634
Conversation
There was a problem hiding this comment.
Pull request overview
This PR removes panic-prone code patterns from the power-policy-service by replacing .expect() and .unwrap() calls with proper error handling. The changes improve the service's robustness by gracefully handling initialization failures and option unwrapping instead of potentially panicking at runtime.
Key changes:
- Replaced
.expect()with proper None handling in PowerPolicy initialization - Refactored
.unwrap()usage by restructuring control flow to use if-let pattern for best_consumer
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| power-policy-service/src/lib.rs | Replaced .expect() on PowerPolicy::create with if-let pattern and early return on None |
| power-policy-service/src/consumer.rs | Replaced .unwrap() on best_consumer with if-let pattern, eliminating early return and simplifying control flow |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
a05f842 to
8c250dc
Compare
8c250dc to
cb2102d
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 8 changed files in this pull request and generated no new comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
0811e05
cb2102d to
0811e05
Compare
Removed panic paths from the `buffer` module. Instead made methods fallible and introduced an `Error` type. Because certain traits are used with methods that assume infallibility (such as the drop and borrow traits), I couldn't just make these return a result. Instead, I added a `Poisoned` status so in the off chance that a `drop` or `borrow` call would have panicked originally, the buffer is marked poisoned and will return a `Poisoned` error on future accesses. This also breaks the interfaces of a few services. For these I added a `Buffer` error and made methods fallible if necessary. I'm not a fan of this since any buffer errors represent an internal programming bug to the service and not something the user should expect/handle, and this breaks encapsulation. I do not want to silently just ignore buffer errors, so I'm not sure what other alternative there is here (open to suggestions). *Edit*: Thinking about maybe renaming the `Buffer` error variant of these services to `Internal` or something. I'd prefer to make it more clear when an error represents an internal invariant being broken that is not something meant to be handled by the caller in any practical manner. It would act as a catchall since the specifics of what caused the error are implementation details that could change any time and not something the caller should be concerned with. Also introduced a `Never` type alias which is useful now that some functions represent never-ending tasks which should never return unless there is an error (see related discussion: #634 (comment)). Resolves #659
No description provided.