Checked vs unchecked exceptions
Moritz Maxeiner via Digitalmars-d
digitalmars-d at puremagic.com
Mon Jun 26 12:31:53 PDT 2017
On Monday, 26 June 2017 at 18:31:50 UTC, jag wrote:
> On Monday, 26 June 2017 at 17:43:08 UTC, Moritz Maxeiner wrote:
>>> Here's the point: with checked exceptions good programmers
>>> can write good code.
>>
>> With checked exceptions any programmer is forced to
>> a) annotate every single function with the complete aggregate
>> of the exceptions that may be thrown by itself or the
>> functions it calls
>> b) violate checked exceptions and limit its callers by marking
>> itself as throwing a parent exception
>>
>
> Here's an example C# pseudocode to illustrate the problem:
No need, you can assume the people discussing this are familiar
with the issue, it's not new.
>
> class A {
> public static void startFoo() {
> if (/* Foo is not installed */)
> throw new FooNotInstalled();
> // ...
> }
> }
>
> Programmer B calls the above code like this:
>
> class B {
> try {
> A.startFoo();
> }
> catch (FooNotInstalled) {
> // Tell user to purchase Foo
> }
> }
>
> Later programmer A updates his code because there are newer
> versions of Foo and he needs the newest version:
>
> class A {
> public static void startFoo() {
> if (/* Foo is not installed */)
> throw new FooNotInstalled();
> if (/* Foo version is too old */)
> throw new FooVersionTooOld();
> // ...
> }
> }
>
> Now the code written by Programmer B crashes even though it
> compiles file. That's bad.
>
> Had this been Java, programmer would be would be alerted to the
> fact that he needs to decide what do do if the version of Foo
> is too old. This is good.
And the good *way* to achieve this result would be the following:
- When visiting `startFoo`, the compiler automatically aggregates
all different exceptions it may throw and stores the resulting set
- If `startFoo` is going to be part of a (binary) library and its
symbol is exported, also export its exception set
- Improve the compiler's nothrow analysis such that if startFoo
is called in scope S, but all of the exceptions in its exception
set are caught (i.e. can't break out of scope S), it is treated
as nothrow in S.
- Enclose the call to `startFoo` in B in a nothrow scope.
>
> So listing exceptions that can be thrown is a good thing
> because it helps you write more reliable code.
It is a bad thing because you force a human to do a machine's job.
More information about the Digitalmars-d
mailing list