aiohttp-jsonrpc icon indicating copy to clipboard operation
aiohttp-jsonrpc copied to clipboard

__JSONRPC_EXCEPTIONS__ field for exception mapping

Open vladalexeev opened this issue 5 years ago • 3 comments

I suggest a mechanism of not using exception mapping in the global scope.

You can define exception mapping in a view:

class JSONRPCTestService(JSONRPCView): __JSONRPC_EXCEPTIONS__ = { CustomServerException: CustomServerException.code }

The view will search an exception in this field, and if there is no such exception then fall back to the global exception mapping

On the client-side, you can also define exception mapping for ServerProxy like this

class CustomServerProxy(ServerProxy): __JSONRPC_CODES__ = { CustomClientException.code: CustomClientException }

The ServerProxy will search error code in this field and raise the appropriate exception. If there's no such code in __JSONRPC_CODES__, then it falls back global exception mapping.

Thus, you can have several views, which raises the same kind of exception, but return them with different codes. And also you can have several ServcerProxy objects for different kinds of services, which error code sets intersect.

vladalexeev avatar Jul 08 '20 06:07 vladalexeev

Actually you may add rule for serialize custom exception via singledispatched aiohttp_jsonrpc.common.py2json object.

It's faster than this solution.

So it's my mistake, I should have added it to README

mosquito avatar Jul 08 '20 12:07 mosquito

The problem of singledispatched py2json is that it's global. And it cannot solve my problem.

I need to have several ServerProxy objects to different kinds of services, which sets of json-rpc codes intersect. And I need different exceptions to be raised from different ServerProxy.

And on the other side, I run several services in tests as mocks and their json-rpc codes also intersect. I cannot use the method register_exception because they will interfere with each other.

For example, two services have errors with code 123. But for the first service, it means that it cannot find an object by id, and for the second service, it means that it can't do an action. One code but different meanings for different services. I would like to use different types of exceptions for it.

My proposal is to have the ability to explicitly separate sets of codes and exceptions by different services.

vladalexeev avatar Jul 08 '20 13:07 vladalexeev

In protection of my pull request, I should say that it solves also the problem when error codes of a service intersect with error codes of clients. For example, we create a service, which methods raise exception InvalidParameters = 1001. We published with exception and code using register_exception methods. And this service makes calls to another JSON-RPC service, which methods raise exception ObjectNotFound with the same code 1001. Thus, when we get from the client service error with code 1001, we get an InvalidParameters exception instead of ObjectNotFound.

My pull request gives the way to solve this problem.

Is there a chance the pull request will be accepted and merged into the main repository?

vladalexeev avatar Nov 18 '20 05:11 vladalexeev