Skip to content
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

Closed
bbkr opened this issue Apr 2, 2016 · 4 comments
Closed

Shall we suggest Foo::Bar::X::What::Happened exception name format? #11

bbkr opened this issue Apr 2, 2016 · 4 comments

Comments

@bbkr
Copy link

bbkr commented Apr 2, 2016

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 but Foo::Bar::X::What::Happened is better because:

  • It is clear which part is the name of package and which is the name of exception. Let's take old X::User::Access::Auth::Invalid for example - did we have problem with accessing authorization system from User class or did we simply get wrong credentials in User::Access class? Defining this as User::Access::X::Auth::Invalid makes things explicit - we have separate class for user access and it got wrong credentials.
  • It is lexically scoped - exception What::Happened can be defined in Foo::Bar class and exported.
  • When ecosystem will grow we will encounter many conflicts in X:: namespace. For example people will be defining exceptions like X::ParamMissing and use them in Foo::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 use X:: format to refactor them while ecosystem is still young) ?

@quietfanatic
Copy link

I agree with this and all its rationales. Things defined by a module should all be in that module's namespace.

@AlexDaniel
Copy link
Member

AlexDaniel commented Jul 16, 2019

I didn't know this ticket existed, so I filed another one: #11 Raku/problem-solving#57

This repo will likely be unified with problem-solving in the future, so I'm closing this ticket in favor of the other one.

@vrurg
Copy link

vrurg commented Jul 16, 2019

I think you meant Raku/problem-solving#57

@AlexDaniel
Copy link
Member

Ah, yes! Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants