Tibor17 commented on pull request #486: URL: https://github.com/apache/maven-surefire/pull/486#issuecomment-1065981465
@slawekjaranowski @hboutemy @olamy What's the difference between these constructors? What's the difference between these two exceptions. The purpose of both exceptions (`MojoExecutionException` and `MojoFailureException`) is written with the example of m-compiler-p in the Javadoc. Briefly speaking, the `MojoFailureException` is related to a config error, e.g. user error as for instance you configure the parameter `parallel` on the provider which does not support the `parallel` exec. On the other hand the `MojoExecutionException` is the error of the plugin itself. Basically, this is wrong question and should not be given to me because I did not create this API for Plugins and I am not the author of `SurefireHelper.java`. This code existed here for years. I remember I these calls of exceptions maybe 8 years ago. It means that the author of them knew that it should be called this way. One can be wondering why we alter the constructors even if the second parameter is null. I am wondering about it too, but the most important is the result. I tried to call all constructors but this actually works properly and the message is as expected too. Pls give me a hint if you can, I appreciate it. The fact is that the clients are wondering why there is the stack trace on the console, and some users are asking these questions on the **StackOverlow**. These questions are bad for us especially in case of `BUILD FAILURE` because the stack trace gives a bad impression to the users that the the problem is in the plugin and I saw the colleagues of mine in the companies that they are not scrolling up to see the test error, there is no reason to print the stack trace if the `firstForkException` is null. Sometimes the newbies users do not understand that they should scroll higher a bit to see that the bottom is not important, but their practices come from they daily experiences of another tools where only exceptions are important to see and so the people sometimes filter our all relevant messages on the console, so they have this selective read abilities. So the stack trace is annoying if it is irrelevant to see for them. These questions regarding existence of exceptions should not be given to me as I am not the author of the `Maven Plugin API`. These exceptions were here always. I do not see any reason why we should not use them. We have always used them, so I am only preventing showing stack trace when should not be shown on the console. The exceptions have been used for many years, even before when I entered the ASF. It means that the exceptions have certain purpose for the author. The questions could be given to @krosenvold or @agudian as well, who were our colleagues and they are in the same situation as me or you or anybody else, which means that we use the API still the same way for years and we respect the API. I can see another reason why these questions are rised up, and they are not very technical, and I have to say that the same is elaborated in Olivier's PR and Olivier does not want to accept my arguments that the exceptions are two, we have to respect the API and the purpose, and the most imporant argument is that it is very silly to report **BUILD FAILURE if -Dmaven.test.failure.ignore=true** - try to read it because it is really funny to ignore my argument which explains that the users wants to ignore failures in the build but we finish the build with FAILURE. That's the reason why I recommended to Olivier to throw a **specific** exception as an error and not a failure. Why I want to recommend it? Because the developers make mistakes in the future and it is better to show them that `MojoExecutionException` is intended in the particular **IF statement**. Removing the calls of `MojoExecutionException` would be maybe a benefit in Olivier's PR but definitelly it would not be the rightest right decision. Mostly if the `firstForkException` is not null the plugin throws `BUILD ERROR` and the stack trace makes sense because it is the real internal error. There is one more situation and it is the timeout. It is not a typical failure doe to the JVMs have been timedout and stopped - the JVM were stopped abruptly - with exit error code. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
