> I feel that I don't have a good understanding of your
> definition of when exception are not used as return
> values.
> Maybe you can elaborate.

If an exception gets thrown, it propagates up the call stack automatically. Code on the call stack need not do anything actively to support this behaviour. Basically, exceptions are transparent to application code.

This is not true for return values. Return values are never transparent to any application code. Application code always needs to know what to expect and what a specific return value does mean.

This is a fundamental difference between exceptions and return values. Now, you can start to model the behaviour of exceptions by using return values in a certain consistent way in your application code. Granted, this will never be really transparent to your application, but you do create a kind of metalevel code upon which you build your application. The better choice, though, is native support in the language, the way exception mechanisms provide. You can also start to model the behaviour of return values by using exceptions. You just need to define which exceptions you throw upon which conditions and stop using return values for the named cases. Clients of function/method interfaces are forced to handle exceptions instead of return values. You obtain the very same effect like you used return values.

So, when don't you use exceptions as a replacement for return values? When, as an implementor of a function/method interface, you do not name/document the exceptions you throw. Because, if you do, these are not really transparent to the application code anymore. If code is aware of and behaves depending on the concrete types of exception thrown by called code, the transparency is gone, the exceptions become part of the contract and could as well be modeled by usage of return values.

> This is not true for return values. Return values are
> never transparent to any application code. Application
> code always needs to know what to expect and what a
> specific return value does mean.

well, you could ignore the return-value.

> This is a fundamental difference between exceptions and
> return values. Now, you can start to model the behaviour
> of exceptions by using return values in a certain
> consistent way in your application code. Granted, this
> will never be really transparent to your application, but
> you do create a kind of metalevel code upon which you
> build your application. The better choice, though, is
> native support in the language, the way exception
> mechanisms provide. You can also start to model the
> behaviour of return values by using exceptions. You just
> need to define which exceptions you throw upon which
> conditions and stop using return values for the named
> cases. Clients of function/method interfaces are forced to
> handle exceptions instead of return values. You obtain the
> very same effect like you used return values.

Right.

> So, when don't you use exceptions as a replacement for
> return values? When, as an implementor of a
> function/method interface, you do not name/document the
> exceptions you throw.

right, but you probably document whether the functions can throw or not.

> Because, if you do, these are not
> really transparent to the application code anymore. If
> code is aware of and behaves depending on the concrete
> types of exception thrown by called code, the transparency
> is gone, the exceptions become part of the contract and
> could as well be modeled by usage of return values.

Your views are quite reasonable. If an exception is not documented, it is not part of the contract.
I think I had two points with my original post

1. even if you don't know what exception is thrown, knowing that one can be thrown or not is part of the contract

2. even if you don't know what exception is trown, knowing the state of some relevant objects if it is thrown may be part of the contract

best regards

Thorsten

> > This is not true for return values. Return values are
> > never transparent to any application code. Application
> > code always needs to know what to expect and what a
> > specific return value does mean.
> well, you could ignore the return-value.

But then you know you do actively ignore something. With exceptions (the non-documented, the not-used-like-return values) this is completely transparent (and this has been the initial motivation for exceptions, I guess).

> > So, when don't you use exceptions as a replacement for
> > return values? When, as an implementor of a
> > function/method interface, you do not name/document the
> > exceptions you throw.
> right, but you probably document whether the functions can
> throw or not.

Documenting that the function can/does throw an exception (possibly in circumstances you don't specify clearly, even without stating the exact exception type) is essentially the same as defining an integer return value with 0 on success, -1 on failure.

> If an exception is not
> documented, it is not part of the contract.

Yes. I wish, the article would clearify this.

> I think I had two points with my original post
> 1. even if you don't know what exception is thrown,
> knowing that one can be thrown or not is part of the
> contract

Agree completely, see above.

> 2. even if you don't know what exception is trown, knowing
> the state of some relevant objects if it is thrown may be
> part of the contract

Richtig. Both cases belong to my exceptions-used-like-return-values view.

> Richtig. Both cases belong to my
> exceptions-used-like-return-values view.

In other words exceptions-used-as-program-flow-control-constructs to aid return values handling.