New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

try to avoid non jdk runtime exceptions in code #3763

Closed
romani opened this Issue Jan 27, 2017 · 3 comments

Comments

Projects
None yet
4 participants
@romani
Member

romani commented Jan 27, 2017

We should avoid usage of non-jdk exceptions that could be thrown from our code.
org.apache.commons.beanutils.ConversionException should be changed to IllegalArgumentException.
Whole code should be reviewed to fins similar cases.
Try to forbid this by ImportControl check.

import org.apache.commons.beanutils.ConversionException;
.....
public class RightCurlyCheck extends AbstractCheck {
.....
    public void setOption(String optionStr) {
        try {
            option = RightCurlyOption.valueOf(optionStr.trim().toUpperCase(Locale.ENGLISH));
        }
        catch (IllegalArgumentException iae) {
            throw new ConversionException("unable to parse " + optionStr, iae);
        }
}
@rnveach

This comment has been minimized.

Show comment
Hide comment
@rnveach

rnveach Feb 27, 2017

Member

fix is merged

Member

rnveach commented Feb 27, 2017

fix is merged

@rnveach rnveach closed this Feb 27, 2017

@rnveach rnveach added this to the 7.7 milestone Feb 27, 2017

@mkordas

This comment has been minimized.

Show comment
Hide comment
@mkordas

mkordas Apr 11, 2017

Contributor

@romani what was wrong with using non-JDK exceptions? Are there any articles or blog posts saying it is a bad practice?

Contributor

mkordas commented Apr 11, 2017

@romani what was wrong with using non-JDK exceptions? Are there any articles or blog posts saying it is a bad practice?

@romani

This comment has been minimized.

Show comment
Hide comment
@romani

romani Apr 12, 2017

Member

@mkordas , just minimization of dependencies to thirdparty libraries for no reason in our project.
It is not idea for new Check :). Just desire to keep usage of classes under control and do not use smth fancy from thirdparty library is there is analog/similar class in jdk.

Member

romani commented Apr 12, 2017

@mkordas , just minimization of dependencies to thirdparty libraries for no reason in our project.
It is not idea for new Check :). Just desire to keep usage of classes under control and do not use smth fancy from thirdparty library is there is analog/similar class in jdk.

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