`*_exclusive_errors`

What it does

This is formed of 6 lints:

• crate_exclusive_errors: Functions can only return error types from within their crate.

  In src/lib.rs, don't do this:

  pub fn my_function() -> Result<(), std::io::Error> { /* ... */ }
  

  do this:

  pub struct MyCrateError(std::io::Error);
  pub fn my_function() -> Result<(), crate::MyCrateError> { /* ... */ }
  

• module_exclusive_errors: Functions can only return error types from within their module.
  This is a superset of crate_exclusive_errors.

  In src/my_module.rs, don't do this:

  pub fn my_function() -> Result<(), crate::MyCrateError> { /* ... */ }
  

  do this:

  pub struct MyModuleError(std::io::Error);
  pub fn my_function() -> Result<(), MyModuleError> { /* ... */ }
  

• function_exclusive_errors: Functions can only return error types from within their module and no 2 functions can return the same error type.
  This is a superset of module_exclusive_errors.

  In src/my_module.rs, don't do this:

  pub enum MyModuleError {
      One(std::io::Error),
      Two(std::num::TryFromIntError)
  }
  pub fn my_first_function() -> Result<(), MyModuleError> { /* ... */ }
  pub fn my_second_function() -> Result<(), MyModuleError> { /* ... */ }
  

  do this:

  pub struct MyFirstFunctionError(std::io::Error);
  pub struct MySecondFunctionError(std::num::TryFromIntError);
  pub fn my_first_function() -> Result<(), MyFirstFunctionError> { /* ... */ }
  pub fn my_second_function() -> Result<(), MySecondFunctionError> { /* ... */ }
  

• crate_name_errors: When an error type is defined at the root of a crate (lib.rs or main.rs) it should be named <crate name in pascal case>Error.

• module_name_errors: When an error type is defined within a module it should be named <module name in pascal case>Error.

• function_name_errors: When an error type is exclusively returned by 1 function it should be named <function name in pascal case>Error.
  This supersedes module_name_errors and crate_name_errors where it applies

Advantage

Enforces a standard coding practice for error granularity throughout a project, offering an ascending level of strictness/descriptiveness.

Drawbacks

• module_exclusive_errors: Requires a notable amount of code.
• function_exclusive_errors: Requires a significant amount of code.

Possible additional lints

Categories

I would suggest the categories:

• crate_exclusive_errors: pedantic
• module_exclusive_errors: pedantic or restriction
• function_exclusive_errors: restriction
• crate_name_errors: restriction
• module_name_errors: restriction
• function_name_errors: restriction

Start with the six proposed lint behaviors and the examples in src/lib.rs and src/my_module.rs. Review how the requested crate-, module-, and function-level exclusivity and naming rules should relate, then define the scope and tests needed for all six lints; done means the agreed rules are implemented and validated.