macgregor/alexandria

View on GitHub
alexandria-core/src/main/java/com/github/macgregor/alexandria/BatchProcess.java

Summary

Maintainability
B
4 hrs
Test Coverage

Method execute has a Cognitive Complexity of 21 (exceeds 5 allowed). Consider refactoring.
Open

    public void execute(Batch<T> batch, Task<T> task, AfterBatch<T> after) throws BatchProcessException {
        try {
            for (T t : batch.collect(context)) {
                try {
                    task.execute(context, t);

Cognitive Complexity

Cognitive Complexity is a measure of how difficult a unit of code is to intuitively understand. Unlike Cyclomatic Complexity, which determines how difficult your code will be to test, Cognitive Complexity tells you how difficult your code will be to read and comprehend.

A method's cognitive complexity is based on a few simple rules:

  • Code is not considered more complex when it uses shorthand that the language provides for collapsing multiple statements into one
  • Code is considered more complex for each "break in the linear flow of the code"
  • Code is considered more complex when "flow breaking structures are nested"

Further reading

Method execute has 45 lines of code (exceeds 25 allowed). Consider refactoring.
Open

    public void execute(Batch<T> batch, Task<T> task, AfterBatch<T> after) throws BatchProcessException {
        try {
            for (T t : batch.collect(context)) {
                try {
                    task.execute(context, t);

    Refactor this method to reduce its Cognitive Complexity from 19 to the 15 allowed.
    Open

        public void execute(Batch<T> batch, Task<T> task, AfterBatch<T> after) throws BatchProcessException {

    Cognitive Complexity is a measure of how hard the control flow of a method is to understand. Methods with high Cognitive Complexity will be difficult to maintain.

    See

    Extract this nested try block into a separate method.
    Open

                    try {

    Nesting try/catch blocks severely impacts the readability of source code because it makes it too difficult to understand which block will catch which exception.

    Define and throw a dedicated exception instead of using a generic one.
    Open

            Collection<T> collect(Context context) throws Exception;

    Using such generic exceptions as Error, RuntimeException, Throwable, and Exception prevents calling methods from handling true, system-generated exceptions differently than application-generated errors.

    Noncompliant Code Example

    public void foo(String bar) throws Throwable {  // Noncompliant
      throw new RuntimeException("My Message");     // Noncompliant
    }
    

    Compliant Solution

    public void foo(String bar) {
      throw new MyOwnRuntimeException("My Message");
    }
    

    Exceptions

    Generic exceptions in the signatures of overriding methods are ignored, because overriding method has to follow signature of the throw declaration in the superclass. The issue will be raised on superclass declaration of the method (or won't be raised at all if superclass is not part of the analysis).

    @Override
    public void myMethod() throws Exception {...}
    

    Generic exceptions are also ignored in the signatures of methods that make calls to methods that throw generic exceptions.

    public void myOtherMethod throws Exception {
      doTheThing();  // this method throws Exception
    }
    

    See

    Define and throw a dedicated exception instead of using a generic one.
    Open

            void execute(Context context, T t) throws Exception;

    Using such generic exceptions as Error, RuntimeException, Throwable, and Exception prevents calling methods from handling true, system-generated exceptions differently than application-generated errors.

    Noncompliant Code Example

    public void foo(String bar) throws Throwable {  // Noncompliant
      throw new RuntimeException("My Message");     // Noncompliant
    }
    

    Compliant Solution

    public void foo(String bar) {
      throw new MyOwnRuntimeException("My Message");
    }
    

    Exceptions

    Generic exceptions in the signatures of overriding methods are ignored, because overriding method has to follow signature of the throw declaration in the superclass. The issue will be raised on superclass declaration of the method (or won't be raised at all if superclass is not part of the analysis).

    @Override
    public void myMethod() throws Exception {...}
    

    Generic exceptions are also ignored in the signatures of methods that make calls to methods that throw generic exceptions.

    public void myOtherMethod throws Exception {
      doTheThing();  // this method throws Exception
    }
    

    See

    T is not used in the interface.
    Open

        public interface AfterBatch<T> {

    Type parameters that aren't used are dead code, which can only distract and possibly confuse developers during maintenance. Therefore, unused type parameters should be removed.

    Noncompliant Code Example

    int <T> Add(int a, int b) // Noncompliant; <T> is ignored
    {
      return a + b;
    }
    

    Compliant Solution

    int Add(int a, int b)
    {
      return a + b;
    }
    

    Define and throw a dedicated exception instead of using a generic one.
    Open

            boolean execute(Context context, Collection<AlexandriaException> exceptions) throws Exception;

    Using such generic exceptions as Error, RuntimeException, Throwable, and Exception prevents calling methods from handling true, system-generated exceptions differently than application-generated errors.

    Noncompliant Code Example

    public void foo(String bar) throws Throwable {  // Noncompliant
      throw new RuntimeException("My Message");     // Noncompliant
    }
    

    Compliant Solution

    public void foo(String bar) {
      throw new MyOwnRuntimeException("My Message");
    }
    

    Exceptions

    Generic exceptions in the signatures of overriding methods are ignored, because overriding method has to follow signature of the throw declaration in the superclass. The issue will be raised on superclass declaration of the method (or won't be raised at all if superclass is not part of the analysis).

    @Override
    public void myMethod() throws Exception {...}
    

    Generic exceptions are also ignored in the signatures of methods that make calls to methods that throw generic exceptions.

    public void myOtherMethod throws Exception {
      doTheThing();  // this method throws Exception
    }
    

    See

    There are no issues that match your filters.

    Category
    Status