Refactor `morley-client`
Clarification and motivation
I see two things we need to improve after !287 (merged) (not there because it's :so-big: already):
- Now
morley-client
tentatively consists of 3 major parts: abstract interface, RPC-based methods andtezos-client
-based methods. However, module structure is flat. I propose to group functionality so that there are 3 groups corresponding to these parts. - Exceptions are quite sad. For instance, when a transaction is sent such that contract execution fails, the following exception will be thrown:
PreApplyFailed [RuntimeError{},ScriptRejected{}]
. It's much less convenient to work with than it would be with something likeClientMichelsonFailed SomeValue
. As a consequence, error handling inmorley-nettest
doesn't fully work yet.
Acceptance criteria
-
morley-client
functionality is grouped better to reflect the aforementioned parts (abstract, RPC andtezos-client
). - For each error that we can imagine to be caught by a user of
morley-client
(such as insufficient balance,[FAILED]
value from a contract, etc.) there is an easy-to-work-with exception constructor. They should be properly handled bymorley-nettest
.