-
Notifications
You must be signed in to change notification settings - Fork 1.7k
proposal: strict_exceptions
(safe/unsafe concept to make Dart more predictable)
#58934
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
Comments
strict_dart
(safe/unsafe concept to make Dart more predictable)strict_exceptions
(safe/unsafe concept to make Dart more predictable)
If you really want to have checked exceptions, consider an annotation like @Throws<FormatException>() which also says which exception is thrown. The "Good" example of } on FormatException catch(e) { ... } and ensure that all annotated exceptions are caught. It does mean that the lint needs to check every method call of an annotated method, each It's not clear whether you can annotate functions, or only methods. @Throws<X>()
int Function(String) createParse(int radix) => ...; It's unclear whether this annotates the Same issue for int Function(@Throws<X>() int Function(String) parse, String source) f; Can we put annotations on function type parameters at all? It's a structural type, so it doesn't really exist as an entity. Might also need to have some rules about overriding in subclases. Seems like something needing a big effort, but the optionality of it is very Dart 1-ish (an optional, pluggable type system.) I also wouldn't use this for errors (aka, thrown objects implementing |
@bernaferrari can you say whether this is different from #58232? That is our lint request with the most upvotes |
It seems really similar. I'll close this. Thanks! |
Uh oh!
There was an error while loading. Please reload this page.
strict_exceptions
Details
I love Rust safeness. I dislike when someone calls
firstWhere
and it throws. Or when someone doeshttp.get
and it fails (by throwing an exception). Or when someone callsjson.decode
and something bad happens. These errors usually happen on runtime and are unpredictable. Uber had an issue where something that might never happen happened when a server call went rogue. Certain kind of runtime issues could be avoided in Dart, I believe.Maaaaybe, Dart could have an annotation like
@unsafe
that the analyzer uses to check if certain code can or cannot crash. It wouldn't affect anything else, but it would surely be a helper for people that want a stricter code with greater warranties that it won't misbehave.JavaScript has strict mode, which eliminates silent errors. I wish Dart had a similar feature (although this would be way more strict than JS).
With sealed classes, most of these weird exception situations (like http.get) could be wrapped into a Result: Success | Error scenario, like Kotlin. Therefore, unpredictable places throwing an exception could be an even stronger motivation for my strict mode proposal.
Biggest challenge is figuring out how plug-ins would work with this lint when not opted in.
Kind
Guard against runtime unpredictable exceptions. Allow the user to have a predictable execution.
Bad Examples
Good Examples
The text was updated successfully, but these errors were encountered: