-
Notifications
You must be signed in to change notification settings - Fork 0
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
feat(errors): add error class and functions #113
Conversation
Signed-off-by: james-a-morris <[email protected]>
a5fdbd2
to
c9bde71
Compare
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.
Don't forget to add the package to the Dockerfile
|
||
export class AssertError extends IndexerError { | ||
constructor(message: string) { | ||
super(AssertError.name, message); |
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.
does this mean that the HTTP response body will be
{
error: "AssertError",
message: message
}
or not necessary
?
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.
Correct - this would be the toJSON()
if we tried to stringify it
*/ | ||
export abstract class IndexerHTTPError extends IndexerError { | ||
constructor( | ||
private readonly httpStatusCode: StatusCodes, |
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.
should we make this optional and set a default code? 400 or 500
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 think it should be intentional otherwise we'd want to use IndexerError
Co-authored-by: amateima <[email protected]>
* Generic Error class that should be used in the Indexer to | ||
* provide common error patterns to log | ||
*/ | ||
export abstract class IndexerError extends 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.
this seems more generalized than indexer, since we could use this package in other applications, should we reflect that in the naming?
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.
Quite possibly - I will leave it to @alexandrumatei36 as this may be out of scope to consider non-indexer applications
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.
@james-a-morris we can do a quick renaming. I agree with David that we should design these packages as they would be used in the future in other repos/apps too
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'd prefer to avoid naming it just Error
when dropping the Indexer
. How about FormattedError
?
Signed-off-by: james-a-morris <[email protected]>
Signed-off-by: james-a-morris <[email protected]>
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 is great work! It can be merged after renaming the error class
resolved offline - we'll follow in post |
Initial PR to integrate a uniform data payload in the API