refactor: replace anyhow

[Murasko]

This pull request refactors error handling throughout the codebase to replace the use of the generic anyhow::Error with custom, strongly-typed error enums for configuration and provider-related operations. This makes error handling more precise and improves error reporting. The most significant changes include the introduction of ConfigError and ProviderError types, their integration into the main application logic, and the propagation of these error types through the CLI and provider interfaces.

Error Handling Refactor:

• Introduced a new ConfigError enum in src/config.rs to handle configuration loading and parsing errors, replacing anyhow::Error throughout the configuration code. All relevant functions now return Result<T, ConfigError> and propagate this error type. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14]
• Added a new ProviderError enum in src/provider/error.rs that unifies errors from all DNS providers and is now used as the error type for the Provider trait methods. All provider implementations and trait signatures have been updated to use this error type instead of anyhow::Error. [1] [2] [3] [4] [5] [6]

CLI and Application Logic Adjustments:

• Updated CLI commands and error enums to use the new ConfigError and ProviderError types, improving the specificity of error messages shown to users. Added new error variants for argument validation in src/cli/get.rs. [1] [2] [3] [4] [5]
• Updated the main application error handling in src/main.rs to integrate the new error types, including a small change to box RuntimeError for consistency. [1] [2]

Dependency and Code Clean-up:

• Removed the dependency on anyhow in Cargo.toml and all code files, as it is no longer needed after migrating to custom error types. [1] [2] [3]

These changes collectively improve the robustness and clarity of error handling across the application, making it easier to diagnose and handle specific error cases.

[Copilot]

Pull request overview

This pull request successfully refactors the codebase to replace the anyhow error handling crate with custom, strongly-typed error enums (ConfigError and ProviderError). The refactoring improves type safety and makes error handling more explicit throughout the application.

Changes:

• Introduced ConfigError enum for configuration-related errors with specific variants for IO, YAML parsing, unknown providers, and unknown DNS types
• Introduced ProviderError enum to unify error handling across all DNS provider operations, wrapping provider-specific errors and common failure cases
• Updated all provider implementations (Hetzner, Nitrado, Netcup) to use the new error types with consistent error mapping patterns
• Improved CLI error reporting with specific error variants for argument validation
• Removed the anyhow dependency from the project

Reviewed changes

Copilot reviewed 11 out of 12 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
Cargo.toml	Removed anyhow dependency
Cargo.lock	Updated dependency lock file to reflect anyhow removal
src/config.rs	Added ConfigError enum and updated all configuration functions to return Result<T, ConfigError>
src/lib.rs	Exported ConfigError for external use
src/main.rs	Updated Error enum to use ConfigError instead of anyhow::Error
src/cli/get.rs	Added specific error variants for argument validation and updated to use ProviderError
src/cli/generate_config.rs	Updated to use ConfigError instead of anyhow::Error
src/provider.rs	Updated Provider trait methods to return Result<T, ProviderError>
src/provider/error.rs	Added new ProviderError enum to unify provider error handling
src/provider/hetzner.rs	Updated to use ProviderError with explicit error mapping
src/provider/nitrado.rs	Updated to use ProviderError with explicit error mapping
src/provider/netcup.rs	Updated to use ProviderError with explicit error mapping

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 11 out of 12 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (2)

src/provider/hetzner.rs:106

• This expect() call can panic if the API key contains invalid characters for HTTP headers. Since ProviderError::InvalidApiKey exists (defined in error.rs line 33), this should return that error instead of panicking. Consider using .parse().map_err(|_| ProviderError::InvalidApiKey)? or adding a helper method that validates the API key and returns a proper error.

        headers.insert(
            "Auth-API-Token",
            self.provider_config.api_key.parse().expect("Invalid Hetzner API key: contains characters that are not allowed in HTTP headers"),

src/provider/nitrado.rs:68

• This unwrap() call can panic if the formatted Bearer token contains invalid characters for HTTP headers. Since ProviderError::InvalidApiKey exists (defined in error.rs line 32-33), this should return that error instead of panicking. Consider using .parse().map_err(|_| ProviderError::InvalidApiKey)?

        headers.insert(
            "Authorization",
            format!("Bearer {}", self.provider_config.api_key)
                .parse()
                .unwrap(),

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Kitt3120]

ALready looking very good, just some quick fixes for you

[Kitt3120]

Can you check if it makes sense to use individual Error enums for the different methods below instead of having them all return the same general ConfigError enum? Or does every method below actually need all of the enum values? Then using the same ConfigError enum for all of them makes sense. Otherwise, define specific error enums per method.

[Copilot]

Pull request overview

Copilot reviewed 11 out of 12 changed files in this pull request and generated 4 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 11 out of 12 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.

[Kitt3120]

I refactored some code.

There is still 1 discussion open we should resolve before merging. Also, there are some clippy warnings left. Please run cargo clippy and see if you can fix them.