Checked Exceptions as an annotation

[DevNico]

I never understood the hate checked exceptions get. The solution people give for why you don't need them is either if something went wrong return null which since null safety is a thing you get forced to handle but that doesn't tell me why something went wrong!

The solution proposed for this is usually some kind of Result Object telling wether or not the request was a success as well as more information as to why it failed. This is all fine and good until you have multiple requests and all of them give you a Result. You now have to write code like the following:

final value1 = await myObject.getSomeValue('value1');
final value2 = await myObject.getSomeValue('value2');
final value3 = await myObject.getSomeValue('value3');
final value4 = await myObject.getSomeValue('value4');

if(value1.success && value2.success && value3.success && value4.success) { ... }

The same kind of long and repetitive if has to be written if the function just returns null in case of an error.

If the function threw a checked exception I would be informed that I need to handle the exceptions and one try {} catch {} would solve the problem. This syntax would be way more readable and easier to maintain in my opinion.

Maybe instead of adding checked exceptions as a language feature which has been decided is something dart will not do (See dart-lang/language#984)

Maybe we could add the feature as an annotation? If I could declare my function with an @Throws(SomeException) annotation and then get analyzer support that would already be a huge help since one could just configure the rule to act as an error.

Originally posted by @DevNico in dart-lang/language#984 (comment)

EDIT: Community poll on Reddit

[ChristianKleineidam]

It seems @lrhn suggested in the linked thread that the way to document expections is to add documentation comments like:

/// Defines a flag.
///
/// Throws an [ArgumentError] if there is already an option named [name] or
/// there is already an option using abbreviation [abbr]. Returns the new flag.
Flag addFlag(String name, String abbr) => ...

You could write a lint rule that act on whether there's a paragraph that speaks about expections from function's documentating their expection being catched.

The current problem seems to be that very often expections aren't documented. One way to encourage full documentation of expections of packages would be to only give full points on pub.dev to packages that document all expections that they throw in their public API. We could just make it worth one point to encourage people to do it.

[Abion47]

I greatly disagree with this proposal. Exceptions should be just that - exceptional. Attempting to get a value from a repository carries the possibility of that value not existing in that repository, so it is not an exceptional outcome and therefore a bad use case to throw an exception.

If you are depending on exception handling to drive your primary logic, I argue that that is an antipattern and is an indicator of code smell.