Обработка недопустимого типа данных в удаленной функции CF

Обновление:

Я оставляю это здесь для потомков, так как это объясняет причину ошибки и цепочку событий с проверкой. Однако ответ Адама является правильным решением IMO.

remote string function name (required numeric varname){

Я пытался поместить try/catch вокруг/внутри функции и не работает.

Поскольку значение аргумента проверяется перед, CF выполняет что-либо внутри функции. Так что до try/catch дело даже не доходит.

Если вы хотите разрешить нечисловые значения, вы должны установить тип аргумента string и выполнить проверку внутри функции. то есть

      // use whatever check is appropriate here
      if ( IsNumeric(arguments.varname) ) { 
          // good value. do something
      }
      else {
          // bad value. do something else
      }

Я также пытался установить значение по умолчанию, но все равно получаю сообщение об ошибке

domain.com/path/to/page.cfc?method=function&varname=

Обновить Причина, по которой это не работает, заключается в том, что параметр varname действительно существует. Его значение — пустая строка. Пока передается некоторое значение (даже пустая строка), default игнорируется.

Я не согласен с тем, что принятое решение является лучшим подходом здесь.

Во-первых, если ваш метод ожидает числовое значение, а ему передается строка, то здесь ошибка — это как раз правильная реакция. Вы не должны чувствовать необходимость смягчать запросы, которые передают недопустимые значения. Представьте, что кто-то делает запрос к http://some.domain/path/to/file/wrongOne.html (они должны были запросить http://some.domain/path/to/file/rightOne.html)... совершенно нормально, что вещи возвращают "ошибку" 404, не так ли? Ответ об ошибке точно подходит в этой ситуации.

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

Это пример правила «мусор на входе, мусор на выходе».

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

Лучше допустить ошибку, потому что тогда механизм, запрашивающий URL, перестанет это делать. Плохо возиться, возвращая 200 OK для запроса, который не был "ОК".

Ошибки - когда они являются правильным результатом - это нормально. В них нет ничего плохого.