Skip to content

Conversation

joshprice
Copy link
Contributor

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: []
  1. 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`.
  1. 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`

@joshprice joshprice changed the title Raise helpful errors for DSL section inline and inline+block syntax improvement: raise helpful errors for DSL section inline and inline+block syntax Sep 15, 2025
@@ -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
Copy link
Contributor

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"

Copy link
Contributor Author

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

Copy link
Contributor

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 😂

Copy link
Contributor Author

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?

Copy link
Contributor

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`
```
@joshprice joshprice force-pushed the section-validation-improvement branch from 50a780c to d1d796e Compare September 17, 2025 12:09
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

Successfully merging this pull request may close these issues.

2 participants