Exceptions part of function signature

[Gerard]

Hi,

Is it an option/idea to make the exceptions thrown be part of the
signature of a function?
- So I'll get a warning if I call a function and not handle one of the
exceptions.
- So I'll get an error if I make a derived version and throw new kind of
exception.

Gerard van Dorth

 

[Herfried K. Wagner [MVP]]

Is it an option/idea to make the exceptions thrown be part of the
signature of a function?
- So I'll get a warning if I call a function and not handle one of the
exceptions.
- So I'll get an error if I make a derived version and throw new kind of
exception.

A similar concept was used in Java (checked exceptions) but has not been
introduced to .NET for some good reasons. The article below describes these
reasons, although it's written for C#, it applies to VB.NET too:

Why doesn't C# have exception specifications?
<URL:http://msdn.microsoft.com/vcsharp/team/language/ask/exceptionspecs/default.aspx>

 

[Cor Ligthert]

Herfried,

I was reading the same page, and thought, that is not completly what the OP
asked.

And therefore was not showing the link.



Cor

 

[Herfried K. Wagner [MVP]]

Cor,

I was reading the same page, and thought, that is not completly what the
OP asked.

Huh?! It's exactly part of what the OP asks:

| Is it an option/idea to make the exceptions thrown be part of the
| signature of a function?

No, it's a bad idea because something because its foundation, checked
exceptions, are a bad idea. So, adding checked exceptions is a bad idea,
and making exceptions part of the signature is even worse because, for
example, overloading based on the thrown exceptions wouldn't work.

| - So I'll get a warning if I call a function and not handle one of the
| exceptions.

In Java, code won't compile if you don't handle a checked exception. The
reasons why this does not make much sense are shown in the article I
referenced (versioning, ...).

| - So I'll get an error if I make a derived version and throw new kind of
| exception.

I didn't check how this is solved in Java, but I think this issue is another
problem of checked exceptions.

 

[Gerard]

Herfried,

- Versioning: though true, this holds for more properties of the
signature (so, not a strong argument)

- Code quality: if A calls B, B calls C, C calls D, and D raises an
exception that is eventually handled by A, A normally doesn't know anything
about the context of the exception and hence can't handle "program state"
properly.

- If the number of possible exceptions could be large, so make
checked exceptions optional.

- Impracticality of having class author differentiate between
"checked" and "unchecked" exceptions: If A calls B and B doesn't do the
things it should do, it better raises a checked exception.

 

[Herfried K. Wagner [MVP]]

- Versioning: though true, this holds for more properties of the
signature (so, not a strong argument)

I think it's a tradeoff. In the time of the Java boom I didn't like checked
exceptions because they made everything more complicated without adding more
value. What other properties of a signature add less value than checked
properties would do?

In addition, checked exceptions would not increase code quality, simply
because the avarage programmer would catch it instead of propagating it
using 'throws...' in the procedure's head, and, to make it even worse,
assign an empty exception handler. Checked exceptions always were a
controversial feature in the Java community and subject of discussion.
You'll find many articles on the web discussing checked exceptions and if
they are valuable enough to be added to a programming language. An
interesting article by Bruce Eckel (who authored books about Java) can be
found here:

Does Java need Checked Exceptions?
<URL:http://www.mindview.net/Etc/Discussions/CheckedExceptions>

The last comment on the page referenced above quotes Eric Gunnerson
(<URL:http://discuss.develop.com/archives/wa.exe?A2=ind0011A&L=DOTNET&P=R32820>),
who was one of the designers of C#:

| Examination of small programs leads to the conclusion
| that requiring exception specifications could both enhance
| developer productivity and enhance code quality, but experience
| with large software projects suggests a different result --
| decreased productivity and little or no increase in code quality.

Time has shown that checked exceptions were a bad idea, and thus they were
not included. There was for sure a long process of discussion going on
before this decision.

- Code quality: if A calls B, B calls C, C calls D, and D raises
an exception that is eventually handled by A, A normally doesn't know
anything about the context of the exception and hence can't handle
"program state" properly.

In this case, handle the exception in 'C'. My daily developer experience
shows me that I always keep the documentation opened to lookup the
exceptions thrown by methods I use in my code. I think there are more
evolved concepts to increase code quality than checked exceptions. Checking
for empty exception handlers (using tools like FxCop), using automated tests
(unit testing) and better training are far more effective without affecting
versioning, for example.

- If the number of possible exceptions could be large, so make
checked exceptions optional.

That's what Java does, IIRC.