Closed mattj256 closed 9 years ago
Cool. One detail though - you should definitely return Failure rather than throw an exception. Because throwing an exception will actually throw the exception. That is, the function will either return Success(...) or throw an exception, and it will never return Failure(...).
The way that Try normally integrates with the exception handling is that if you write Try(...some code here...), then it will catch exceptions raised in that block of code, which is convenient.
For some reason I thought that what I did would return a Failure object even though that doesn't really make sense. I'll fix it up and resubmit.
Is this good? The parameter to Failure is a Throwable so I didn't throw the exceptions but I still had to create them. I'm way too new at this to know if I'm doing it the "right" way or not.
Good!
@lightvector I know the Board/Move is on the critical path but I needed something a little easier to work on.
After making my changes I reran the unit tests and made sure localhost:8080 came up correctly. This is hardly exhaustive but it's a lot better than nothing.
Some things to note:
Success()
gave compile warnings so I changed toSuccess(())
throw new XxxException
rather than explicitly returning Failure.I think we should standardize - either return Failure or throw an exception, but do it the same way every time.