← 输入框|github.com|刷新
Skip to content

Suggestion: Sonar S1130 "throws" declarations should not be superfluous #1061

Open

Description

@jlerbsc

Hi,

After suggesting that you correct this type of defect automatically (#1051 ), we are offering another code smell correction.

In your project it seems that some methods throw runtime exceptions that it is not useful to declare because it inherits for example from the RuntimeException class.

https://rules.sonarsource.com/java/RSPEC-1130

If this is of interest to you we can push code changes to you in the form of a PR.

Below are examples of the changes made by our software to correct this rule.

org\biojava\nbio\aaproperties\xml\AminoAcidCompositionTable.java
@@ -133,5  +133,5 @@
 * 	thrown if AminoAcidCompositionTable.computeMolecularWeight(ElementTable) is not called before this method
 */
-	public double getMolecularWeight(Character aaSymbol) throws NullPointerException{
+	public double getMolecularWeight(Character aaSymbol) {
	if(this.aaSymbol2MolecularWeight == null){
		throw new NullPointerException("Please call AminoAcidCompositionTable.computeMolecularWeight(ElementTable) before this method");

org\biojava\nbio\alignment\io\StockholmFileParser.java
@@ -284,5  +284,5 @@
 *             if unexpected format is encountered
 */
-	public StockholmStructure parse(String filename) throws IOException, ParserException {
+	public StockholmStructure parse(String filename) throws IOException {
	InputStream inStream = new InputStreamProvider().getInputStream(filename);
	StockholmStructure structure = parse(inStream);

Activity

  1. josemduarte commented on May 17, 2023

    @josemduarte
    Contributor

    That sounds reasonable to me: not declaring unchecked exceptions would follow the style that we try to have elsewhere in the biojava library.

    As a note: there's a school of thought (see blogpost) that believes that checked exceptions are evil and that one should convert everything to unchecked and declare the unchecked exceptions in signatures for documentation purposes. In any case, I'm not saying we should do that with BioJava now, it would quite a disruptive change.

  2. jlerbsc commented on May 18, 2023

    @jlerbsc
    ContributorAuthor

    Do you agree that I submit a PR to you soon on this subject? For information, fixes will be made by our solution which automatically resolves defects in java applications.

  3. josemduarte commented on May 18, 2023

    @josemduarte
    Contributor

    Yes, we'd be happy to review a PR.

  4. jlerbsc commented on May 21, 2023

    @jlerbsc
    ContributorAuthor

    Regarding the link you indicated, i consider that checked exceptions give meaning to methods. Of course, as in many areas, there are always supporters and detractors. It seems to me that the article bears witness to a very personal conviction and another person could perfectly well find contradictory scenarios. Personally, I'm very comfortable with checked exceptions and I don't find that managing these exceptions is so restrictive. Everyone sees noon at his door.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions