The Artima Developer Community
Sponsored Link

Articles Forum
Contract Programming 101

18 replies on 2 pages. Most recent reply: Jan 25, 2006 4:05 AM by Jussi Santti

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 18 replies on 2 pages [ « | 1 2 ]
Radek Liba

Posts: 7
Nickname: radek
Registered: Dec, 2005

Re: Contract Programming 101 Posted: Jan 24, 2006 8:12 AM
Reply to this message Reply
Advertisement
> 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.

Thorsten Ottosen

Posts: 4
Nickname: nesotto
Registered: Dec, 2003

Re: Contract Programming 101 Posted: Jan 24, 2006 12:58 PM
Reply to this message Reply
> 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

Radek Liba

Posts: 7
Nickname: radek
Registered: Dec, 2005

Re: Contract Programming 101 Posted: Jan 25, 2006 12:52 AM
Reply to this message Reply
> > 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.

Jussi Santti

Posts: 3
Nickname: jussi
Registered: Jun, 2005

Re: Contract Programming 101 Posted: Jan 25, 2006 4:05 AM
Reply to this message Reply
> 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.

Flat View: This topic has 18 replies on 2 pages [ « | 1  2 ]
Topic: The Desktop as a Grid Service Previous Topic   Next Topic Topic: Modular Architectures with Ruby

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use