-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(errors): add custom error classes #508
Conversation
Signed-off-by: jriffs <mayjriffs97@gmail.com>
} | ||
|
||
registerActor<T extends AbstractActor>(_cls: Class<T>): Promise<void> { | ||
throw new Error("GRPC is currently not supported."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There might be more such errors now introduced in some PRs like #485
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've searched the repo and there doesn't seem to be anymore files with those errors or similar errors
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
okay, I have found and updated it.
Quick question0- Do i create a new folder errors
in the test
directory to place the unit test files or do i just add them to an existing folder in the same test
directory
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They should be a part of https://github.com/dapr/js-sdk/tree/main/test/unit/<an-existing-folder>
to test if components return the correct error, and also in https://github.com/dapr/js-sdk/tree/main/test/unit/errors
to test the error itself.
Signed-off-by: jriffs <mayjriffs97@gmail.com>
Codecov Report
@@ Coverage Diff @@
## main #508 +/- ##
==========================================
- Coverage 35.69% 35.22% -0.47%
==========================================
Files 87 90 +3
Lines 10125 10142 +17
Branches 414 415 +1
==========================================
- Hits 3614 3573 -41
- Misses 6452 6503 +51
- Partials 59 66 +7
|
cfd3823
to
de37df0
Compare
src/version.ts
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file has appeared again, I wonder is your IDE doing some magic 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@shubham1172 I think it is doing some magic lol 😅, I suspect it does this when i run npm run pretty-fix
command, but I'll be on the lookout next time. Could you please 🙏 give me a few pointers on how to resolve the code coverage issue, how do i test that each component returns the right error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@shubham1172 still waiting on your response sir 😇
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @jriffs, sorry this got lost in my GitHub notifications, thanks for pinging. For code coverage, I think it is okay to skip testing "GRPCNotSupportedError" or "HTTPNotSupportedError" since we usually do not write tests for unimplemented code anyway.
For PropertyRequiredError, we can create unit tests under test/unit/http
, for e.g. workflow.ts and with a similar pattern like HttpServerImpl.test.ts, we can expect methods to throw a certain error.
@@ -23,7 +24,7 @@ export default class GRPCClientWorkflow implements IClientWorkflow { | |||
} | |||
|
|||
get(_instanceId: string, _workflowComponent?: string | undefined): Promise<WorkflowGetResponseType> { | |||
throw new Error("Method not implemented."); | |||
throw new MethodNotImplementedError(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be same as GrpcNotSupportedError, I don't think we will need MethodNotImplemented error then.
src/version.ts
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @jriffs, sorry this got lost in my GitHub notifications, thanks for pinging. For code coverage, I think it is okay to skip testing "GRPCNotSupportedError" or "HTTPNotSupportedError" since we usually do not write tests for unimplemented code anyway.
For PropertyRequiredError, we can create unit tests under test/unit/http
, for e.g. workflow.ts and with a similar pattern like HttpServerImpl.test.ts, we can expect methods to throw a certain error.
Signed-off-by: jriffs <mayjriffs97@gmail.com>
de37df0
to
f365bbd
Compare
Hi @shubham1172 , i just wanted to ask if there were any problems with the PR, if there are none, i was wondering if you could maybe assign me to a new issue so i can get working on that. |
Thanks @jriffs, leaving it open for some time to get more eyes. Meanwhile you could pick up the good first issue from the next milestone https://github.com/dapr/js-sdk/milestone/13 :) |
Description
Added custom error classes
GRPCNotSupportedError
andHTTPNotSupportedError
and updated the following classes to use the new custom errors-src/implementation/Client/HTTPClient/configuration.ts
-src/implementation/Client/HTTPClient/proxy.ts
-src/implementation/Server/GRPCServer/actor.ts
#297