Есть сообщение с полем типа string, могу ли я анализировать это поле?

Question

[Archy901]

есть поле (тип string) "value": "ОК" / "Error" - то есть два возможных значения. Могу ли я на основании значения вывести что-то соответствующее. Например если пришло "OK" - написать "everything is good", а если пришло "Error" написать "something wrong". Это вообще нормальная практика анализировать строку? Или для этого надо использовать boolean type или int?

Answer 1

[Толстый Лорри]

if(value.equals("OK"))  { ... }

switch(value) {
    case "OK": ... break;
    case "Error": ... break;
}

Строковых параметров для проверки некоторого ограниченного списка значений лучше избегать (нужно будет предусматривать ситуации с разными кейсами, пробелами внутри, опечатками, которые не отследить при компиляции и прочее), вместо них можно использовать boolean или enum-типы (если больше двух значений).

enum Status {
    Ok,
    Error,
    Warning
}

class Foo {
    static void bar(Status status) {
        if (status == Status.Ok) {
            ... 
        }
        ...
    }
}

Comments

[Archy901]

спасибо, все очень здорово объяснили!

[pi314]

И, кстати, для проверки значения enum тоже можно (и нужно!) использовать switch() / case. Это делает код намного более читаемым. А, кроме того, код с enum гораздо лучше расширяется, если, например, в один прекрасный день окажется, что возможно не два, а больше разных значений. Это в любом случае намного лучше, чем бросаться исключениями...

[Толстый Лорри]

pi314: > код с enum гораздо лучше расширяется
А в чем проблема расширять наборы строк?

> Это в любом случае намного лучше, чем бросаться исключениями.
Это еще почему?

[pi314]

Free_ze: 1. Строки для заявленного сценария - вообще зло. Если они не константы (т.е. значения могут прилететь извне), то их нужно как минимум проверять на валидность, null/empty/Upper/LowerCase и пр. пританцовывания... а если константы, то зачем выкидывать на них столько памяти, если можно обойтись enum с той же самой выразительностью, но гораздо дешевле по ресурсам плюс - и это основное преимущество - проверка компилятором? Серьезно рассматривать строки как альтернативу тут как-то даже неудобно... но, если конкретно по вопросу: как минимум, меньше кода при расширении. Сравните private static String CASE_NUMBER_THREE = "мой новый супер-пупер кейс"; против добавления CASE_NUMBER_THREE в enum :) Хотя, конечно, если говнокодить, то особой разницы действительно не будет :)

2. Примерно по тем же соображениям. Даже если не знать, что обработка исключений в смысле ресурсов еще дороже, чем обработка строк, и отвлечься от того, что на каждый новый случай придется заводить новый класс исключения (я тут, опять же, не рассматриваю говнокодовские практики упаковки всего и вся в строковый месседж внутри java.lang.Exception, который, кроме бешенных накладных расходов, мало чем отличается от строк), то исключение - конструкция языка, предназначенная для информирования НЕИЗВЕСТНОГО получателя о ситуации, которая не может быть обработана в той части кода, которая его бросает. Именно от этого они, при бездумном использовании, имеют свойство пролетать на самый верх и ронять все приложение. В описанном сценарии ни в том, ни в другом нет никакой необходимости. Для этого случая enum - наиболее адекватная конструкция языка.

Хотя, конечно, если очень хочется, то можно все, ибо, забивать шуруп молотком все же проще, чем закручивать гвоздь отверткой :)

[Толстый Лорри]

pi314: > Сравните

Нет, бойлерплейта в сравнении с enum там не много. Про остальное я говорил.

> обработка исключений в смысле ресурсов еще дороже

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

> каждый новый случай придется заводить новый класс исключения

То есть заводить новый код ошибки - это ОК, а новый класс исключения унаследовать - это плохо?

> исключение - конструкция языка, предназначенная для информирования НЕИЗВЕСТНОГО получателя

Если вы стараетесь делать loosely coupled code, то каждый отдельный модуль будет тем самым НЕИЗВЕСТНЫМ получателем.

> при бездумном использовании, имеют свойство пролетать на самый верх

Ага, то есть не моргнув глазом оставлять приложение в логически неверном состоянии - лучшее решение? Да и никто не мешает в удобном месте перехватывать и логгировать все подряд. А то, что они умеют "всплывать" - это безумно удобная фича, избавляющая от тонны проверок и ручного "пробрасывания".

ЗЫ Для исключений и кодов результата есть свои ниши, сценарии применения. Но слепо говорить, что что-то из этого не нужно - просто глупо.

[pi314]

Free_ze : Или мы по-разному интерпретируем суть вопроса, или же у нас развивается полемика "ниочем" :) В моем понимании, автора вопроса интересует лучшая практика для конкретного сценария "КОД ОШИБКИ"... в частности, для 2 возможных значений. В этом смысле я полностью согласен с вашим ответом. Для случая же возможного расширения утверждаю, что строки и исключения ощутимо хуже enum. Почему:

>То есть заводить новый код ошибки - это ОК, а новый класс исключения унаследовать - это плохо?
Да, плохо... т.к. для этого сценария неоправдано дорого.
- Самый дешевый код ошибки - статическая константа, например, int. Из недостатков: консистентность значений не может быть проверена компилятором, плюс, при сериализации теряется мнемоника.
- Чуть дороже enum. Стоимость одного кода ошибки в enum, грубо, если отбросить прочие накладные расходы VM, Строка + оrdinal. Преимущества: гарантированый синглтон, гарантированная (компилятором) корректность, мнемоническая сериализация, values()/valueOf(), ну, и, разумеется, чисто эстетическое удовольствие от того же сравнения по == вместо богопротивного equals() :)
- Строка выглядит на первый взгляд дешевле, но если учесть, что в реализованном говнокодом сценарии реально создается минимум 2 экземпляра строки (при "заполнении" и при "сравнении"), мнимое преимущество теряется... а недостатки остаются. (А если не говнокодом, то, опять же, у строки нет преимуществ перед static final int, кроме недостатков.)
- Исключение - самое дорогое, что можно придумать. Один безполезный (для сценария!) стектрейс впридачу чего стоит... про приятные неожиданности в реализации на разных VM, например, проброса из цикла, даже заикаться не буду :) Лучшая практика относительно исключений - не использовать их всуе, т.е. если в этом нет конкретной осознанной необходимости.

В контексте вопроса такой необходимости явно нет и ваш аргумент про loose coupling для данного сценария бряд ли уместен. Если кто-то проверяет код ошибки, ему по определению известен класс или, как минимум, реализуемый объектом интерфейс, а значит, и сигнатуры всех методов, так что, вопрос - если ничего не дофантазировать - сводится всего навсего к выбору адекватного типа результата. Не знаю, как Вы, а я, лично, задумался бы о профпригодности коллеги, написавшего

public void getError() throws Error1Exception, Error2Exception {...

:)

Надеюсь, что мне удалось исчерпывающе аргументировать, почему именно enum - лучшая практика для сценария "КОД ОШИБКИ". По поводу остальных ваших аргументов ничего не могу сказать, т.к., к сожалению, не понимаю, с кем Вы спорите по этим моментам... я ничего подобного не утверждал :)

[Толстый Лорри]

pi314: я не согласен с "кодом _ошибки_". Ошибка - это нештатная ситуация, исключительная. Так что давайте говорить про код возврата или статуса)

[pi314]

Free_ze: Полностью с Вами согласен! Это определенно была моя неточность... правильнее говорить о "коде результата".

[Толстый Лорри]

pi314: спасибо

Answer 2

[Konstantin Malyarov]

Если конечный результат будет иметь значение да/нет, OK/error, true/false лучше использовать boolean, если значений больше двух - int.

Вообще использовать string как индикатор результата удачно/неудачно - плохая затея.

Лучше использовать string как расшифровка значения. Допустим значение boolean - false, значение string "Операция завершилась неудачно, boolean - true, значение string "Операция завершилась удачно".

Comments

[Archy901]

спасибо огромное!

Answer 3

[Андрей Шишкин]

Сделайте метод void. В случае если в логике метода может что-то пойти не так, не надо возвращать ни boolean, ни int. Кидайте исключение.
В итоге у вас получится:
Если ОК - просто выполнили логику
Если Error - кинули Exception