Katello/katello — pull request #2427 by pitr-ch (2013-06-05 08:14:57+00:00)
Title: Do not hide exceptions

This pull-request does two things:

## Adds gem `justified`

_taken from readme_

A mini-gem to add missing **causes** to exception `backtrace`-s like Java has. This gem will add following at the bottom of a `backtrace`:

from caused by: (AnError) an ugly bug
from justified.rb:83:in `bad_code'
from ... skipped 4 lines

Exception cause can be also accessed with `#cause` method which returns `nil` or an `Exception`.

### Example

```ruby
require 'justified/standard_error'

begin
raise 'a cause'
rescue
raise 'an exception'
end
```

will print

```
file.rb:6:in `rescue in

': an exception (RuntimeError)
from file.rb:3:in `

'
from caused by: (RuntimeError) a cause
from file.rb:4:in `

'
from ... skipped 0 lines
```

- Documentation:
- Source:
- Blog:

### Why am I adding this?

It allows to raise new exceptions from current layer/abstraction without dropping the original cause for the new exception.

Good example what it helps to do is in [`http_resource.rb`](https://github.com/Katello/katello/blob/dbc46dcb8fbb0e61ce4704379ac3467d6a43180e/app/lib/http_resource.rb#L114-L117).

## Disables hiding of exceptions

I've disabled exception hiding in `application_controller.rb` for development and testing environment. I had time only to disable it in UI controllers for now. I'll do the same for API controllers next TDD.

I think that hiding an exception is relevant only in production mode where the exception needs to be hidden form an user. On the other hand it should not be hidden In development and testing from a developer. Exceptions should be allowed to bubble up and be seen and fixed. By disabling the hiding it showed about 30 false positive tests which I've fixed in this PR.

There is a common anti-pattern I've seen in controller actions. An action tries to do its job without any testing of parameters. If parameters are wrong (which is not an exceptional state) the action with fail with an exception which is handled by `rescue_from` and by returning state 500. This is problematic for several reasons:

* user sees 500 (server error) and an ugly exception instead of correct 400 (bad request)
* relying on exceptions to handle bad parameters, an expected error cannot be distinguished from an actual bug/error in code
* using exceptions to control program flow

Where I needed to fix action to detect bad parameters I've started using method `return render_bad_parameters`. If you detect bad parameters please consider using same method.