Хороший способ инкапсулировать Integer.parseInt ()

Вы можете использовать Null-Object следующим образом:

public class Convert {

    @SuppressWarnings({"UnnecessaryBoxing"})
    public static final Integer NULL = new Integer(0);

    public static Integer convert(String integer) {

        try {
            return Integer.valueOf(integer);
        } catch (NumberFormatException e) {
            return NULL;
        }

    }

    public static void main(String[] args) {

        Integer a = convert("123");
        System.out.println("a.equals(123) = " + a.equals(123));
        System.out.println("a == NULL " + (a == NULL));

        Integer b = convert("onetwothree");
        System.out.println("b.equals(123) = " + b.equals(123));
        System.out.println("b == NULL " + (b == NULL));

        Integer c = convert("0");
        System.out.println("equals(0) = " + c.equals(0));
        System.out.println("c == NULL " + (c == NULL));

    }

}

Результатом main в этом примере является:

a.equals(123) = true
a == NULL false
b.equals(123) = false
b == NULL true
c.equals(0) = true
c == NULL false

Таким образом вы всегда можете проверить на наличие неудачного преобразования но все равно работать с результатами как с экземплярами Integer. Вы также можете настроить число NULL , представляющее (0).

Это несколько похоже на решение Николая:

 private static class Box<T> {
  T me;
  public Box() {}
  public T get() { return me; }
  public void set(T fromParse) { me = fromParse; }
 }

 private interface Parser<T> {
  public void setExclusion(String regex);
  public boolean isExcluded(String s);
  public T parse(String s);
 }

 public static <T> boolean parser(Box<T> ref, Parser<T> p, String toParse) {
  if (!p.isExcluded(toParse)) {
   ref.set(p.parse(toParse));
   return true;
  } else return false;
 }

 public static void main(String args[]) {
  Box<Integer> a = new Box<Integer>();
  Parser<Integer> intParser = new Parser<Integer>() {
   String myExclusion;
   public void setExclusion(String regex) {
    myExclusion = regex;
   }
   public boolean isExcluded(String s) {
    return s.matches(myExclusion);
   }
   public Integer parse(String s) {
    return new Integer(s);
   }
  };
  intParser.setExclusion("\\D+");
  if (parser(a,intParser,"123")) System.out.println(a.get());
  if (!parser(a,intParser,"abc")) System.out.println("didn't parse "+a.get());
 }

Основной метод демонстрирует код. Другой способ реализовать интерфейс Parser, очевидно, - просто установить "\ D +" из конструкции, а методы ничего не делать.

Моя Java немного ржавая, но позвольте мне посмотреть, смогу ли я указать вам в правильном направлении:

public class Converter {

    public static Integer parseInt(String str) {
        Integer n = null;

        try {
            n = new Integer(Integer.tryParse(str));
        } catch (NumberFormatException ex) {
            // leave n null, the string is invalid
        }

        return n;
    }

}

Если возвращаемое вами значение null , у вас неправильное значение. В противном случае у вас есть действительное целое число .

Я бы хотел Предлагаем вам рассмотреть такой метод, как

 IntegerUtilities.isValidInteger(String s)

, который вы затем реализуете по своему усмотрению. Если вы хотите, чтобы результат был возвращен - возможно, потому что вы все равно используете Integer.parseInt () - вы можете использовать трюк с массивом.

 IntegerUtilities.isValidInteger(String s, int[] result)

, где вы устанавливаете result [0] в целочисленное значение, найденное в процессе.

Может быть, вы можете использовать что-то вроде этого:

public class Test {
public interface Option<T> {
    T get();

    T getOrElse(T def);

    boolean hasValue();
}

final static class Some<T> implements Option<T> {

    private final T value;

    public Some(T value) {
        this.value = value;
    }

    @Override
    public T get() {
        return value;
    }

    @Override
    public T getOrElse(T def) {
        return value;
    }

    @Override
    public boolean hasValue() {
        return true;
    }
}

final static class None<T> implements Option<T> {

    @Override
    public T get() {
        throw new UnsupportedOperationException();
    }

    @Override
    public T getOrElse(T def) {
        return def;
    }

    @Override
    public boolean hasValue() {
        return false;
    }

}

public static Option<Integer> parseInt(String s) {
    Option<Integer> result = new None<Integer>();
    try {
        Integer value = Integer.parseInt(s);
        result = new Some<Integer>(value);
    } catch (NumberFormatException e) {
    }
    return result;
}

}

Вы также можете очень просто воспроизвести желаемое поведение C ++

public static boolean parseInt(String str, int[] byRef) {
    if(byRef==null) return false;
    try {
       byRef[0] = Integer.parseInt(prop);
       return true;
    } catch (NumberFormatException ex) {
       return false;
    }
}

Вы можете использовать такой метод:

int[] byRef = new int[1];
boolean result = parseInt("123",byRef);

После этого переменная результат это правда, если все прошло нормально, и byRef [0] содержит проанализированное значение.

Лично я бы остановился на перехвате исключения.

Прочитав ответы на вопрос, я думаю, что инкапсуляция или упаковка метода parseInt не нужна, возможно, даже не очень хорошая идея.

Вы можете вернуть 'null', как предложил Джон, но это более или менее заменяет конструкцию try / catch нулевой проверкой. Есть лишь небольшая разница в поведении, если вы «забываете» обработку ошибок: если вы не поймаете исключение, присваивания не будет, и переменная с левой стороны сохраняет свое старое значение. Если вы не проверяете значение null, вы, вероятно, столкнетесь с JVM (NPE).

Предложение yawn кажется мне более элегантным, потому что мне не нравится возвращать null, чтобы сигнализировать о некоторых ошибках или исключительных состояниях. Теперь вам нужно проверить ссылочное равенство с предопределенным объектом, что указывает на проблему. Но, как утверждают другие, если вы снова забудьте проверить, и String не поддается синтаксическому анализу, программа продолжает работать с обернутым int внутри вашего объекта 'ERROR' или 'NULL.

Решение Николая еще более объектно-ориентировано и будет работать с методами parseXXX из других классов-оболочек. Но, в конце концов, он просто заменил NumberFormatException на исключение OperationNotSupported - опять же, вам нужен метод try / catch для обработки неразборчивых входных данных.

Итак, мой вывод - не инкапсулировать простой метод parseInt. Я бы инкапсулировал только, если бы мог добавить еще и некоторую (зависящую от приложения) обработку ошибок.

Решение еще более объектно-ориентировано и будет работать с методами parseXXX из других классов-оболочек. Но, в конце концов, он просто заменил NumberFormatException исключением OperationNotSupported - опять же, вам нужен метод try / catch для обработки неразборчивых входных данных.

Итак, мой вывод - не инкапсулировать простой метод parseInt. Я бы только инкапсулировал, если бы мог добавить еще (зависящую от приложения) обработку ошибок.

Решение еще более объектно-ориентировано и будет работать с методами parseXXX из других классов-оболочек. Но, в конце концов, он просто заменил NumberFormatException на исключение OperationNotSupported - опять же, вам нужен метод try / catch для обработки неразборчивых входных данных.

Итак, мой вывод - не инкапсулировать простой метод parseInt. Я бы инкапсулировал только, если бы мог добавить еще и некоторую (зависящую от приложения) обработку ошибок.

Какого поведения вы ожидаете, если это не число?

Если, например, вы часто используете значение по умолчанию, когда ввод не является числом, тогда используйте такой метод, как это может быть полезно:

public static int parseWithDefault(String number, int defaultVal) {
  try {
    return Integer.parseInt(number);
  } catch (NumberFormatException e) {
    return defaultVal;
  }
}

Подобные методы могут быть написаны для другого поведения по умолчанию, когда ввод не может быть проанализирован.