Skip to content
This repository has been archived by the owner on Jan 21, 2020. It is now read-only.

Catch Exceptions From Inputs #33

Conversation

ashireman
Copy link

  • When InputFilter is validating, catch Exceptions thrown by Inputs
  • Return ApiProblemResponse (422) with message
  • Previous behavior was to return Fatal with Stack Trace and (200)
  • Test to confirm fix

Fixes issue #32

Tony Shireman added 2 commits January 14, 2015 08:53
- When InputFilter is validating, catch Exceptions thrown by Inputs
- Return ApiProblemResponse (422) with message
- Previous behavior was to return Fatal with Stack Trace and (200)
- Test to confirm fix
throw exceptions the validator will now return the proper response.
@michalbundyra
Copy link
Member

First of all FilterInvalidArgumentException is not defined.

I tested your changes on default PHP configuration (5.4 and 5.5) and your test does not cover your changes in the code. Please generate coverage in PHPUnit to see it.

I had a look on DateTime validator and actually it could throw an exception, but it will be an exception of type Zend\Validator\Exception\InvalidArgumentException.
Besides, it looks more like the exception is thrown not really during validation, but during initialization (for example intl, btw. by default intl does not throw any exceptions: http://php.net/manual/en/intl.configuration.php#ini.intl.use-exceptions).

if ($inputFilter->isValid()) {
return;
}
} catch (FilterInvalidArgumentException $ex) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As noted by another reviewer, this is not a valid exception type.

In fact, looking through the various exceptions thrown by Zend\Filter, the only time I see InvalidArgumentException thrown is typically for setters; DateTimeFormatter and the various File filters are anomalies here.

Additionally, also noted by another reviewer, validators may also throw exceptions, so type-hinting against filter exceptions only will mean those bubble outwards.

As such, this should likely be hinting against Exception, which also means that the message must change. I'll note that below.

@weierophinney
Copy link
Member

While I do think catching exceptions makes sense here, I also think the approach needs more thinking. In almost all situations, we cannot know if the error is a bad value, or rather due to bad configuration or environmental concerns; in most cases that an exception is thrown from a filter or validator, it's one of these latter two at fault. As such, I feel a 500 status code with a standard error response such as we use in the dispatch.error listeners would make more sense.

@weierophinney
Copy link
Member

Closing due to inactivity.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants