Added Exc variants of all methods in frustum that required them.

[oxt3479]

This PR also includes unit tests for these new functions to verify the behave the same as their exception throwing counterparts.

Signed-off-by: Owen Thompson oxt3479@rit.edu

[cary-ilm]

The Vec classes take the opposite convention: V3f::normalize() does not throw; V3f::normalizeExc() throws.

It seems we have two choices:

1. Let the Frustum methods be inconsistent
2. Be consistent but change the API: projectPointToScreen() would not throw (it current does); add new projectPointToScreenExc() that does throw.

Also, the integer specializations of Vec{2,3,4}::normalize() do throw, which makes them inconsistent.

Also, the Matrix classes take a different approach, with Matrix{22,33,44}::inverse(bool) takes an argument that specifies whether to throw or no. This means there's no method that can be marked noexcept.

I would vote for consistency, and for an API in which the most basic behavior is to not throw, with specially-named methods that do.

Thoughts?

[lgritz]

My preference is default noexcept everywhere, and occasional varieties that can throw and have names that make it totally obvious that they do.

[kdt3rd]

thanks! Had a few comments

[cary-ilm]

@oxt3479, we discussed this and would prefer this convention:

projectPointToScreen() does not throw and is marked "noexcept".
projectPointToScreenExc() throws on error.

Same with the others. Thanks!

[meshula]

Fantastic! Thanks for this!

[cary-ilm]

@kdt3rd, are your request changes resolved? Can you clear them so we can merge?