fix: ArgResults.operator[] should throw Exception not Error

[eseidel]

ArgResults.operator[] and ArgResults.option() would throw ArgumentError instead of Exception when the user would fail to pass all expected arguments.

Errors are only supposed to be thrown on programmer error so changed to throw ArgParserException instead.

Fixes #872

This is a breaking change!

[eseidel]

I'm honestly not sure if this is worth landing, as there is a non-trivial risk of breaking lots of apps in the wild.

[github-actions]

PR Health

Breaking changes ✔️

Package	Change	Current Version	New Version	Needed Version	Looking good?
args	None	2.7.0	2.7.0	2.7.0	✔️

Changelog Entry ✔️

Package	Changed Files

Changes to files need to be accounted for in their respective changelogs.

Coverage ✔️

File	Coverage
pkgs/args/lib/src/arg_results.dart	💚 88 %

This check for test coverage is informational (issues shown here will not fail the PR).

API leaks ✔️

The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API.

Package	Leaked API symbols

License Headers ✔️

// Copyright (c) 2025, the Dart project authors. Please see the AUTHORS file
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.

Files
no missing headers

All source files should start with a license header.

[munificent]

Yeah, I like the spirit of this change, but actually rolling it out seems like a nightmare. I definitely don't have time to actively maintain args. If someone else on the Dart team wants to drive this through shipping, I support it, but I can't shepherd it myself.

[devoncarew]

I definitely don't have time to actively maintain args.

FYI, you're getting these reviews due to a recent change to the https://github.com/dart-lang/core/blob/main/.github/CODEOWNERS file; if you'd prefer not to get them, feel free to update that file (likely to change the reviewers to the ecosystem team).

I'm honestly not sure if this is worth landing, as there is a non-trivial risk of breaking lots of apps in the wild.

I suspect that the mandatory feature probably shouldn't have landed; this use of errors instead of exceptions was introduced then. We have a next-breaking-release label; it could serve to queue this change up for consideration later.

Separately, I wonder if the least overall disruption for users is changing the exception type, or, removing the mandatory option? Removing the option would let people know that they had work to update their code.

[munificent]

FYI, you're getting these reviews due to a recent change to the https://github.com/dart-lang/core/blob/main/.github/CODEOWNERS file; if you'd prefer not to get them, feel free to update that file (likely to change the reviewers to the ecosystem team).

Oh, well how about that. Sent a PR: #891

I suspect that the mandatory feature probably shouldn't have landed; this use of errors instead of exceptions was introduced then. We have a next-breaking-release label; it could serve to queue this change up for consideration later.

Yeah, I didn't love it when I first saw that go by. Definitely a well-intentioned feature, but it doesn't fit very well with existing API for how args works.

Separately, I wonder if the least overall disruption for users is changing the exception type, or, removing the mandatory option? Removing the option would let people know that they had work to update their code.

The least painful option is to probably leave things as they are with the current exception type. If we do want to support mandatory options, we should probably re-work the API so that you can't get your hands on an ArgResults at all if any of the mandatory options are missing. In other words, validate that all mandatory options are present during parsing time, and not when options are accessed from results.