-
Notifications
You must be signed in to change notification settings - Fork 5
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
Shall we suggest Foo::Bar::X::What::Happened exception name format? #11
Comments
I agree with this and all its rationales. Things defined by a module should all be in that module's namespace. |
I didn't know this ticket existed, so I filed another one: This repo will likely be unified with problem-solving in the future, so I'm closing this ticket in favor of the other one. |
I think you meant Raku/problem-solving#57 |
Ah, yes! Thank you! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
https://docs.perl6.org/type/Exception
There was discussion on IRC how exceptions should be defined in _user modules_.
Current documentation suggests
X::Foo::Bar::What::Happened
butFoo::Bar::X::What::Happened
is better because:X::User::Access::Auth::Invalid
for example - did we have problem with accessing authorization system fromUser
class or did we simply get wrong credentials inUser::Access
class? Defining this asUser::Access::X::Auth::Invalid
makes things explicit - we have separate class for user access and it got wrong credentials.What::Happened
can be defined inFoo::Bar
class and exported.X::
namespace. For example people will be defining exceptions likeX::ParamMissing
and use them inFoo::Bar
class. Exception should be encapsulated. I know that there is:auth
to distinguish package origin but it won't solve the problem.So what is your opinion? Shall we promote in docs
Foo::Bar::X::What::Happened
format (and create issues in modules that useX::
format to refactor them while ecosystem is still young) ?The text was updated successfully, but these errors were encountered: