Prior to this change, all callers of ViewLoader#load were forced to
handle the (checked) IOException declared by the #load method signature.
This resulted in a significant amount of duplicate handling logic where
nothing more than logging the error occured.
Failing to load a view represents a catastrophic error in the
application; i.e. it is not something that can be handled in any way
other than shutting the application down, fixing what is broken and
restarting the application. For this reason, any IOException raised
within ViewLoader#load is now caught, wrapped and re-thrown as an
(unchecked) RuntimeException. This will be handled by the platform's
UncaughtExceptionHandler, and a dialog will be raised to inform the user
that a fatal error has occured.
As a result all try/catch blocks around calls to ViewLoader#load have
now been removed, making for tighter, more readable, and easier to test
code.
In the future, the distinction between errors that are programmatically
recoverable and those that are catastrophic (typically developer errors)
will be used to determine whether methods in the Bitsquare API throw
checked or unchecked exceptions.
Prior to this change, TomP2P's 'PeerAddress' was used heavily throughout
Bitsquare, effectively tying many parts of the system to the TomP2P API
when they otherwise had no need to be aware of TomP2P at all.
The Peer interface (and the new 'network' package to which it belongs)
is designed to provide this missing abstraction and is a step toward
isolating TomP2P functionality as completely as possible--so as to make
the latter easy to test (and easy to replace if necessary).
A very simple TomP2PPeer implementation of the Peer interface has been
provided in the new 'network.tomp2p' package. It is currently just a
wrapper for an underlying PeerAddress object, but it is reasonable to
expect that more functionality will find its way into this class over
time.
This reflects the customizations to Notification originally committed in
revision 1a6fb9, but includes *only* the Notification class instead of
bringing in all related enzo types and resources. We now rely on the
enzo jar for that.
Use `./gradlew run` to build and run Bitsquare directly.
Use `./gradlew shadowJar` to generate a portable, executable jar.
Use `./gradlew packageNative` to generate an installer binary specific
to the platform you are running on.
In the case of Windows, it is necessary to copy the two .dll files in
the `package/` directory to the directory where Bitsquare.exe is
ultimately installed.
Resolves#243
