Package studio.mevera.imperat.exception

Interface ThrowableResolver<E extends Throwable,S extends Source>

Type Parameters:
E - the specific type of exception this resolver can handle, must extend Throwable
S - the type of source that provides context for the command execution, must extend Source
All Known Implementing Classes:
MethodThrowableResolver
Functional Interface:
This is a functional interface and can therefore be used as the assignment target for a lambda expression or method reference.
@FunctionalInterface public interface ThrowableResolver<E extends Throwable,S extends Source>
A functional interface for handling and resolving exceptions that occur during Imperat's command execution flow. Implementations of this interface define custom error handling strategies for specific exception types and source contexts.

This resolver pattern allows for flexible exception handling where different types of exceptions can be handled differently based on their type and the context in which they occurred. For example, permission-related exceptions might be handled differently from syntax errors or internal command failures.

Example usage: 


 ThrowableResolver<CommandSyntaxException, CommandSource> syntaxResolver =
     (exception, context) -> {
         context.source().sendMessage("Invalid command syntax: " + exception.getMessage());
         // Log the error or perform additional cleanup
     };
Since:
1.0
See Also:

  • Method Summary

    Modifier and Type
    Method
    Description
    void
    resolve(E exception, Context<S> context)
    Resolves the given exception within the provided execution context.

  • Method Details

    • resolve

      void resolve(E exception, Context<S> context)
      Resolves the given exception within the provided execution context. This method is called when an exception of type E occurs during command execution, allowing for custom handling such as user notification, logging, cleanup operations, or alternative command flows.

      Implementations should be mindful of:

      • Not throwing additional exceptions unless absolutely necessary
      • Providing meaningful feedback to the command source when appropriate
      • Performing any necessary cleanup or state restoration
      • Logging errors for debugging purposes when needed

      The resolution process should be non-blocking and efficient, as it's part of the critical command execution path.

      Parameters:
      exception - the exception that occurred during command execution, never null
      context - the execution context containing the source, command state, and other relevant information at the time the exception occurred, never null
      Throws:
      RuntimeException - if the resolution process itself fails critically (though implementations should avoid this when possible)
      See Also: