Taking a second look at this: I suggest using the existing Sbot(String) error variant rather than creating an additional variant (SbotInit(String)).
I've found it easier for maintenance to keep a smaller number of variants which bundle together errors of like kind.
Taking a second look at this: I suggest using the existing `Sbot(String)` error variant rather than creating an additional variant (`SbotInit(String)`).
I've found it easier for maintenance to keep a smaller number of variants which bundle together errors of like kind.
Agreed I like having fewer variants too. Even having more generic error types, and using the string "message" within the error for giving more details, could even help debug, such that the the specific string in the "message" can help debug exactly where the error comes from.
Agreed I like having fewer variants too. Even having more generic error types, and using the string "message" within the error for giving more details, could even help debug, such that the the specific string in the "message" can help debug exactly where the error comes from.
in this case I separated them initially because the Sbot error type said "sbot returned an error response",
which is not technically what these sbot intialization errors are. so I changed that error message template too to combine them
in this case I separated them initially because the Sbot error type said "sbot returned an error response",
which is not technically what these sbot intialization errors are. so I changed that error message template too to combine them
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
glyph
not panicing is required for the error handling I'm building in peach_config::wait-for-sbot and is I think a better practice in general
Great. A long-overdue addition. Thanks!
Made a comment about error variants.
@@ -35,2 +35,4 @@/// Go-sbot error.Sbot(String),/// Error initializing Go-sbot.SbotInit(String),Taking a second look at this: I suggest using the existing
Sbot(String)error variant rather than creating an additional variant (SbotInit(String)).I've found it easier for maintenance to keep a smaller number of variants which bundle together errors of like kind.
Agreed I like having fewer variants too. Even having more generic error types, and using the string "message" within the error for giving more details, could even help debug, such that the the specific string in the "message" can help debug exactly where the error comes from.
in this case I separated them initially because the Sbot error type said "sbot returned an error response",
which is not technically what these sbot intialization errors are. so I changed that error message template too to combine them
Thanks for the update. I like the improvement you made to the main
Sboterror message.🙏 🖤