-
-
Notifications
You must be signed in to change notification settings - Fork 35
improvement: raise helpful errors for DSL section inline and inline+block syntax #214
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
base: main
Are you sure you want to change the base?
Conversation
@@ -878,11 +878,37 @@ defmodule Spark.Dsl.Extension do | |||
end | |||
|
|||
unless section.top_level? && path == [] do | |||
defmacro unquote(section.name)(body) do | |||
# Handle mixed syntax - personal_details(opts, do: block) | |||
defmacro unquote(section.name)(opts, [do: _] = _block) do |
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.
🤔 what if we actually just could handle both? Do we want to? We could theoretically just call it with just opts and then call it with just do
and it should "just work"
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.
Feel like this question engages the "why are sections and entities separate?" question raised in a previous issue. Could entities handle everything and simplify the logic? I think so
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.
Possibly but that's a major version bump and an overhaul of the whole Ash ecosystem so I'm not particularly interested in that at the moment 😂
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 pushed up the same handling for mixed entity syntax which was the issue that @marot originally found which I was doing while travelling.
I've got some other changes coming, so will have a think about whether "just doing it" is better than throwing a helpful error.
Either way, a helpful error is better than the horrible errors users currently get, so would it be worth merging this as is?
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 defining a new function just to tell you that you can't call it. If we're going to define a new function that expands the API, and the option exists to make it work, then we should prefer that. If Elixir's undefined function error is confusing then we should fix that.
Currently DSL sections throw confusing error messages for the following DSL declarations: 1. Using inline keyword args instead of block syntax gives ``` ** (Spark.Options.ValidationError) required :first_name option not found, received options: [] ``` 2. Using inline and block syntax throws the following compile error ``` error: undefined function section_name/2 (there is no such import) ``` We now catch these errors and show helpful errors so that the user understands what went wrong and how to fix it. The new errors are as follows: 1. Inline syntax ``` Cannot use inline syntax for DSL section `personal_details`. Use block syntax: `personal_details do ... end`. ``` 2. Mixed inline and block syntax ``` Cannot use both inline syntax and block syntax for DSL section `personal_details`. Use block syntax `personal_details do ... end` ```
50a780c
to
d1d796e
Compare
Currently DSL sections throw confusing error messages for the following DSL declarations:
We now catch these errors and show helpful errors so that the user understands what went wrong and how to fix it. The new errors are as follows: