Add exception-handling for value-less-than-or-equal-to-zero

[McDonnough]

Resolve isssue #113 on the server-side. A corresponding change still has to be implemented in the web client.

[thde]

Great @McDonnough! What do you think about changing the spec to accept values equal to zero? @McDonnough & @lroellin It would make an implementation much easier in my view (also ours).

[McDonnough]

@thde @lroellin
In the case of a compensation, I would leave the check as it is right now. A compensation with an amount of zero or less doesn't make much sense and thus a corresponding message should be displayed to the user in question.
Talking about expenses things work a bit differently, as two checks are made at once and either of them lead to the aformentioned exception. Firstly the amount of the expense is checked for being zero or less (similar to what happens in the case of a compensation) and secondly all the profiteers' shares are checked for being zero or less as well. We could get rid of the second check, only verify that all shares add up to the full expense-amount and ignore all profiteers with a share of zero or less.

Considering this, I propose the following changes to be made [WIP]:

• Change the shares-less-than-or-equal-to-zero-check to only check negative (i.e. less-than-zero) values in ExpenseUtil#checkValuesGreaterThanZero.
• Adapt the logic in ExpenseService#createExpense and ExpenseService#editExpense to be capable of handling profiteers with a share-amount of zero.
• Update the API-documentation:
  • Change VALUE_LESS_THAN_OR_EQUAL_TO_ZERO to VALUE_LESS_THAN_ZERO from here.
  • Remove VALUE_LESS_THAN_OR_EQUAL_TO_ZERO to VALUE_LESS_THAN_ZERO from here.
• Extend the web-client to
  • display a fitting message if a compensation with an amount of zero is submitted to the server.
  • a negative amount is submitted for either a compensation or an expense.

[lroellin]

I agree with you, but we still need to check for negative values. Keep in mind that the web client, which checks this, is not the only consumer of our API. So I would opt to go with a "Value less than zero" approach.

[McDonnough]

You're absolutely right about the negative values. I totally forgot about that as I was fixed on the zero-situation. I updated my comment above to reflect your input.