throw "don't do that!";
Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
I too have this question... I recommend putting this question (and whatever the right answer is) on StackOverflow so it's visible to everyone who does "throw 'foo'' like we both do. :]
I believe that the convention is similar to Java's distinction between checked and unchecked (runtime) exceptions. In Dart, exceptions represent a situation that can happen, but isn't usually expected (i.e., "exceptional" situation). Like trying to open a file that doesn't exist. Error represents a situation that shouldn't happen and is definitely programmer's fault. Like trying to divide by zero.
OutOfMemoryError, OSError, StackOverflowError -- don't align well with "definitely programmer's fault".
> Except in a few special circumstances, idiomatic Dart should throw Errors, but never catch them.
If we should generally only catch Exceptions, and not Errors, why does Future have a method named _catchError_ instead of _catchException_ ?
OutOfMemoryError, OSError, StackOverflowError -- don't align well with "definitely programmer's fault".(Stack and Memory errors could be the programmers fault, if they have un-bounded recursion, but that's besides the point.)
I like the idea that there are two buckets.Bucket A: things that happen that a perfect programmer couldn't avoid even if they tried. Network, Disk, OS, Memory. Anything that steps outside the "environment".Bucket B: all the rest.Questions
- Does this catch everything? Make sense? (Forgetting the actual names for a second...)
- Seems like we're saying Bucket A is Exceptions and Bucket B is Errors, right?
- Seems like the examples above (OS, StackOverflow, OOM) probably align with Bucket B (exception?)
- Assuming 1-3
- New issue on aligning existing values w/ the correct philosophy
- New issue to document said philosophy
2. Error: stuff you don't catch: system and programmatic errors.
expect(() => thing, throwsA(new isInstanceOf<ArgumentError>()));(unrelated observation: that's kinda verbose)
I think in terms of these two buckets as well. Another way to think about them are;
> So my two effective buckets are:
> 1. Exception: stuff you catch: runtime errors.
Things that are recoverable
> 2. Error: stuff you don't catch: system and programmatic errors.
Things that are not recoverable.
use different mechanism