Как я могу избежать использования исключений для управления потоком?

Ответ 1

Похоже, вы действительно хотите вернуть два элемента: код ответа и найденный объект. Вы можете подумать о создании облегченной обертки, которая удерживает их и возвращает их вместе.

public class Pair<K,V>{
  public K first;
  public V second;
}

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

Кроме того, если данные еще не истекли, вы все равно можете вернуть их, но дайте ему код 303, чтобы сообщить им, что он не изменился. Серия 4xx будет сопряжена с null.

Ответ 2

С данным требованием вы не можете этого сделать.

Если вы разработали контракт, добавьте условие и вызовите вызывающего абонента

exists(key): bool

Реализация службы выглядит следующим образом:

if (exists(key)) {
    CustomObject o = get(key, ifModifiedSince);
    if (o == null) { 
      setResponseCode(302);
    } else {
      setResponseCode(200);
      push(o);
   }

} else {
      setResponseCode(400);
}

Клиент остается неизменным и никогда не замечает, что вы предварительно подтвердили его.

Если вы не разработали контракт, вероятно, есть веская причина для этого или, вероятно, это только дизайнер (или архитектор). Но поскольку вы не можете изменить его, вам также не придется беспокоиться.

Затем вы должны придерживаться спецификаций и действовать следующим образом:

 CustomObject o = get(key, ifModifiedSince);

 if (o != null) {
     setResponseCode(200);
     push(o);
  } else {
     setResponseCode(404); // either not found or not modified.
  }

Хорошо, вы не отправляете 302 в этом случае, но, вероятно, так оно и было разработано.

Я имею в виду, что по соображениям безопасности сервер не должен возвращать больше информации, чем это [зонд get (key, date) возвращает только null или object]

Так что не беспокойтесь об этом. Поговорите с вашим менеджером и сообщите ему об этом решении. Комментировать код с этим решением тоже. И если у вас есть архитектор в руке, подтвердите обоснование этого странного ограничения.

Скорее всего, вы не видели этого, и они могут изменить контракт после вашего предложения.

Иногда, когда вы хотите действовать правильно, мы можем пойти не так и поставить под угрозу безопасность нашего приложения.

Общайтесь с вашей командой.

Ответ 3

Вы можете создать специальный окончательный CustomObject как "маркер", чтобы указать неизмененный:

static public final CustomObject UNCHANGED=new CustomObject();

и проверьте соответствие с "==" вместо .equals().

Может также работать, чтобы возвращать значение null без изменений и исключение исключения не существует? Если бы мне пришлось выбрать одно из ваших 3, я бы выбрал 1, потому что это кажется самым исключительным случаем.

Ответ 4

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

public bool exists( String key ) { ... }

Caller мог бы сделать:

if (exists(key)) {
   CustomObject modified = get(key,DateTime.Today.AddDays(-1));
   if (modified != null) { ... }
}

or

try {
    CustomObject modified = get(key,DateTime.Today.AddDays(-1));
}
catch (NotFoundException) { ... }

Ответ 5

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

Я не думаю, что "сценарий, в котором ключ существует, но объект не был изменен" является исключительным, конечно, не ненормальным.

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

Ответ 6

Насколько строго требование для этой сигнатуры метода?

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

Я бы обсуждал это с вашим супервизором, если это вариант.

Ответ 7

Я все равно вернул бы нуль.

Цель свойства - вернуть объект, который был изменен после указанной даты. Если возвращать значение null для какого-либо объекта в порядке, то, конечно, возврат значения null для немодифицированного объекта тоже око.

Я лично вернул бы null для немодифицированного объекта и выбросил исключение для несуществующего объекта. Это кажется более естественным.

Вы совершенно правы, чтобы не использовать исключения для управления потоком BTW, поэтому, если у вас есть только эти 3 варианта, ваш инстинкт кишки прав.

Ответ 8

Вы можете следовать шаблону библиотеки .Net и иметь общедоступное статическое поле readonly в настраиваемом объекте с именем CustomObject.Empty, который имеет тип CustomObject (например, строка. Empty и Guid.Empty). Вы можете вернуть это, если объект не модифицирован (потребитель функции должен будет сравнить с ним).
Изменить: я только заметил, что вы работаете на Java, но принцип по-прежнему применяется

Это дает вам возможность следующего

• Возвращает null, если ключ не существует.

• Возвращает CustomObject.Empty, если ключ существует, но объект не был изменен.

Недостаток заключается в том, что потребитель должен знать разницу между возвращаемым значением null и возвращаемым значением CustomObject.Empty.

Возможно, свойство будет более точно названо CustomObject.NotModified, поскольку Empty действительно предназначен для типов значений, поскольку они не могут быть нулевыми. Кроме того, NotModified будет более легко передавать значение поля потребителю.

Ответ 9

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

Ответ 10

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

У вас есть интерфейс класса, который определяет различные ошибки, которые могут произойти, передавая в CustomObject как параметр для события, если это необходимо.

public interface Callback {
  public void keyDoesNotExist();
  public void notModified(CustomObject c);
  public void isNewlyModified(CustomObject c);
  .
  .
  .
}

Таким образом, вы позволяете разработчику интерфейса обратного вызова определять, что делать, когда происходит событие, и вы можете выбирать через интерфейс, независимо от того, требует ли это условий для получения восстановленного объекта. Наконец, это уменьшает сложность логики при возврате. Ваш метод делает это один раз. Разработчикам API не требуется делать это вообще, как это сделано для них.

Ответ 11

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