Попробуйте / поймайте в конструкторе - рекомендуемая практика?

В коде, который вы показываете, проблемы проверки не возвращаются к коду, который создает этот экземпляр объекта. Наверное, это НЕ ХОРОШО.

Вариант 1:

Если вы поймаете исключение внутри метода/конструктора, обязательно передайте что-то обратно вызывающей стороне. Вы можете поместить поле isValid, которое будет установлено в true, если все работает. Это будет выглядеть так:

private boolean isValid = false;

public FileDataValidator(String[] lineData){

    this.lineData = lineData;
    removeLeadingAndTrailingQuotes();

    try
    {
        validateName();
        validateAge();
        validateTown();
        isValid = true;
    }
    catch(InvalidFormatException e)
    {
        isValid = false;
    }
}

public boolean isValid() {
    return isValid;
}

Вариант 2:

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

public FileDataValidator(String[] lineData){

    this.lineData = lineData;
    removeLeadingAndTrailingQuotes();

    try
    {
        validateName();
        validateAge();
        validateTown();
    }
    catch(InvalidFormatException e)
    {
        throw new com.myco.myapp.errors.InvalidDataException(e.getMessage());
    }

}

Вариант 3:

Третий метод, который я хочу упомянуть, имеет такой код. В вызывающем коде вы должны вызвать конструктор, а затем вызвать функцию build(), которая либо будет работать, либо нет.

String[] lineData = readLineData();
FileDataValidator onePerson = new FileDataValidator();
try {
    onePerson.build(lineData);
} catch (InvalidDataException e) {
    // What to do it its bad?
}

Вот код класса:

public FileDataValidator() {
    // maybe you need some code in here, maybe not
}

public void build(String[] lineData){

    this.lineData = lineData;
    removeLeadingAndTrailingQuotes();

    try
    {
        validateName();
        validateAge();
        validateTown();
    }
    catch(InvalidFormatException e)
    {
        throw new com.myco.myapp.errors.InvalidDataException(e.getMessage());
    }

}

Конечно, функция build() может использовать метод isValid(), который вы вызываете, чтобы убедиться, что это правильно, но исключение кажется мне правильным способом для функции сборки.

Вариант 4:

Четвертый метод, о котором я хочу упомянуть, мне больше всего нравится. Там такой код. В вызывающем коде вы должны вызвать конструктор, а затем вызвать функцию build(), которая либо будет работать, либо нет.

Это похоже на то, как работают JaxB и JaxRS, что похоже на вашу ситуацию.

1. Внешний источник данных — у вас файл, у них входящее сообщение в формате XML или JSON.
2. Код для создания объектов — у вас есть свой код, у них есть свои библиотеки кода, работающие в соответствии со спецификациями в различных JSR.
3. Валидация не привязана к строительству объектов.

Код вызова:

String[] lineData = readLineData();
Person onePerson = new Person();
FileDataUtilities util = new FileDataUtilities();
try {
    util.build(onePerson, lineData);
    util.validate(onePerson);
} catch (InvalidDataException e) {
    // What to do it its bad?
}

Вот код класса, в котором живут данные:

public class Person {
    private Name name;
    private Age age;
    private Town town;
... lots more stuff here ...
}

И код утилиты для сборки и проверки:

public FileDataValidator() {
    // maybe you need some code in here, maybe not
}

public void build(Person person, String[] lineData){

    this.lineData = lineData;
    removeLeadingAndTrailingQuotes();
    setNameFromData(person);
    setAgeFromData(person);
    setTownFromData(person);
}

public boolean validate(Person person) {

    try
    {
        validateName(person);
        validateAge(person);
        validateTown(person);
        return true;
    }
    catch(InvalidFormatException e)
    {
        throw new com.myco.myapp.errors.InvalidDataException(e.getMessage());
    }

}

Вы должны рассмотреть шаблон статической фабрики. Сделайте свой конструктор всех аргументов закрытым. Предоставьте статический метод FileDataValidator(args...). Это принимает и проверяет все аргументы. Если все в порядке, он может вызвать приватный конструктор и вернуть только что созданный объект. Если что-то не удается, сгенерируйте исключение, чтобы сообщить вызывающей стороне, что она предоставила неверные значения.

Я также должен упомянуть, что это: catch (Exception e) { printSomeThing(e); }

Это самый смертоносный антипаттерн, который вы можете сделать с исключениями. Да, можно прочитать какие-то значения ошибок в командной строке, а дальше? Вызывающая сторона (предоставившая неверные значения) не получает информации о неверных значениях, выполнение программы будет продолжено.

Я предпочитаю, чтобы исключения обрабатывались тем фрагментом кода, который знает, как с ними работать. В этом случае я бы предположил, что фрагмент кода, создающий FileDataValidator, знает, что должно произойти, если данные файла недействительны, и с исключениями следует обращаться там (я выступаю за распространение к вызывающей стороне).

Обсуждая передовой опыт, мне кажется, что имя класса FileDataValidator пахнет. Если объект, который вы создаете, хранит данные файла, я бы назвал его FileData - возможно, с методом проверки? Если вы хотите только проверить данные своего файла, то статического метода будет достаточно.