|
|
Do you have a topic you'd like Thorkil to write about? Click
here to send a request. |
Exception Handling (2)
This article is the second about exception handling.
The first one dealt with exception handling in DACS-80x86 (an Ada 83
implementation), where the handling is completely table driven and
does not require any code or data generated in blocks to describe
possible handlers and their applicability.
Here we shall look at a different approach to
exception handling that is used in the SCORE® systems (an Ada 95
implementation).
The DACS-80x86 solution relied upon the ability to
find the return points from call instructions and from these deduce
the placement of the Exception Address Tables. The DACS
generated call instructions are all >direct=
(albeit they may be either near or far adding to the
recognition complexity); and by looking at the call instruction the
entry point to the called subprogram can be located. However, SCORE®,
though almost 100% Ada 83 compatible, has to deal with Ada 95's
dispatching capabilities, where a record object may have associated
subprograms, both for handling operator-like functions and create-
and finalize-routines. When such a record is extended the associated
subprograms may take over the subprograms from the >old
part= and/or extend them
with additional handling. To this end a concept of dispatch-tables
is used that records the subprograms that may need to be called,
when using a particular record. The code generator may only need to
know which index to use in the table and then use an indirect call
to get there. This is quite similar to the way SCORE® C++ handles
inheritance, and that is, of course, not a coincidence.
The use of indirect calls makes it impossible to
apply the DACS-80x86 table technique, because the indirect calling
instruction typically involves either a memory location or a
register (or both), and without knowledge about the memory location
or the register value at the time of call, it is impossible to
determine where the call went.
The DACS-80x86 call method also forced the creation
of frames in all Ada generated code, since the return address from
the calls needed to be found to find the call instruction that
caused this return address to be pushed on the stack. Even very
small subprograms would then get a frame created.
With SCORE®, the point of view is slightly different.
SCORE® wishes to favor the simple >leaf
routines= by only using
frame creation when there is a direct need for it. If it is possible
to get away with a few pushes and a call then that is chosen. Of
course this makes it more difficult to find a call chain at a given
point - you either have to scan the stack for possible return
addresses from calls (and here you might pick up some old outdated
values), or you need external information to inform about the stack
layout and register uses. The latter is provided in the DWARF
debugging information, but being information not loaded onto the
target this makes it impossible for the SCORE® RTS to provide a
complete call chain, but on the other hand: The running program does
not need one!
Instead the SCORE® philosophy is that only routines
that require special attention are given special attention, and the
vehicle used here is a Block Descriptor (BD). BDs are chained
together and originate in the possibly anonymous task that executes
the code. If a subprogram has special needs, these are recorded in a
BD when the subprogram is entered. The BD is allocated as any other
object, initialized as required, linked to the current task=s
BD-list and eventually unlinked from the BD-list when the subprogram
is left again.
Typical >attentions=
are uses of exception handlers, heap (collections), tasks, and
objects requiring finalization. There are bits in a BD that signal
which set is present in the block. For an exception handling block
there is also an indication of whether the handler is active or not.
In the declarative part of the block the exception address is still
not set ( = 0 ), so an exception occurring here cannot be caught by
this block. When the address is set the handler may catch the
exception, and as a part of entering the handler, the address
indicator is cleared again to signal that exceptions within the
handler cannot be caught by the block handler any more.
Inner blocks with exception handlers get their own
BDs as well which are removed again when the inner blocks are left.
Inner blocks typically do not create frames, but reuse the
subprogram=s frame and
there may therefore be several BDs for a subprogram, and only a
subset of these are used as a given point in the code.
An exception is in SCORE® the address of a string
(zero terminated) that is the unique name of the exception. Raising
STANDARD.CONSTRAINT_ERROR uses the address of an external object
(provided by package STANDARD) that describes a string value, the
address of which uniquely identifies the exception.
When an exception is raised, the RTS starts looking
at the BD-list for the task (the newest is always in front). If this
BD does not handle exceptions at all (or after an analysis does not
catch this particular exception) the BD is >left=,
which may involve releasing heap memory, finalizing objects, and
awaiting dependent tasks. The next BD is then considered in the same
way.
Eventually either a BD catches the exception at
hand, or it remains unhandled and terminates the task. The RTS
exception handler uses the exception address saved in the BD to
perform its search for the exception; a successful search will
return the code address for the handler code and subsequently
continue execution there, after having cleared the BD=s
exception address field, and the task now is on its own again.
Ada 95 allows the concept of Exception
Occurrence, where a handler may be passed messages and
information - these may also be created in the handlers or
re-raised. This is a challenge for the RTS, since the memory used to
hold the messages must be allocated somewhere and exist as long as
it is needed. In particular the handling of an exception may raise
an exception in the current task, but also in its parent task (e.g.,
tasking_error, if a child task does not elaborate properly). In such
a case memory may have to be allocated on the stack of another task!
But this is not the place to discuss exception occurrences.
The SCORE® implementation of exceptions is generally
very fast, since it does not have to examine stack content, but can
check the BDs in an efficient way, and since only the important
blocks are recorded. Note that in the actual call chain, when an
exception occurs, there may be any number of invisible subprogram
calls that need no attention and which may be bypassed in the search
for a handler as well as reclaimed from the stack in one step, when
a handler is eventually met. The RTS approach can therefore be very
direct and to the point.
As in SCORE®, the DACS-80x86 RTS would still have to
perform block dependent operations when leaving blocks during
exception handling. With the assumption that most subprograms do not
need special attention, the SCORE® approach lets you >pay=
only when there is reason to, by creating BDs only when these are
called for.
Measurements using the PIWG test suite have shown
that exception handling is faster with SCORE than with DACS-80x86,
so the choice of using explicit block descriptors has proven to be a
sound choice.
 |
About the Author
Thorkil Bjørn Rassmussen has worked with DDC-I for over 20
years. He has a Master of Science, Computer Science, from
University of Copenhagen. Thorkil has substantial experience
with all of the DACS tools and is the key individual
involved in all FAA certifications for the DACS product
line. Thorkil lives with his wife Jane and two children
Jonas and Tine, just outside of Copenhagen, Denmark.
|
[
Back to Top ]
By Linda Rising
risingl@acm.org
www.lindarising.org
Linda has been traveling this month and was unable to share one
of her wonderful articles that so many of us have come to love. So,
we decided to look back in the archives and reprint part of an
article Linda wrote in February 2002. In this article, Linda
describes a very interesting pattern called "It's a
Relationship, Not a Sale".
This pattern rings very close to home for DDC-I, because we are a
very "customer focused" organization. We practice this
pattern throughout DDC-I from the front office staff all the way
through management. Every employee has a customer and in our
company... The Customer is #1!
Pattern Name: It's A Relationship, Not A Sale
Problem: How should we treat customers so they'll be
satisfied with our products?
Context: You are a product developer. You may be part of a
team or a single contributor. You currently play an active role
interfacing with customers or you have been asked to take on this
role.
Jim Coplien's Engage Customers (closely couple
the customer role to the Developer) [Coplien95] and Bruce
Whitenack's Customer Rapport (develop a rapport with the customer)
[Whitenack95] define the context for this pattern.
Forces:
Developers usually have a product focus not a
customer focus.
We want to delight our customers.
We also want to protect our own interests.
Solution: Develop a relationship with the
customer. Focus on this relationship, not the current transaction.
It’s critical to Know the Customer (a Customer
Interaction pattern) and then use that understanding in your product
or service as part of an ongoing commitment to Build Trust (a
Customer Interaction pattern).
Resulting Context: Customers will feel
they're buying into a relationship, not just buying a product. Your
customers will feel like staying with you. Your customers will sense
that you are going somewhere together.
A long-term relationship means repeat business.
It’s much cheaper to keep a customer than to find a new one.
Having a good relationship with a customer is not
enough to ensure financial success. Innovative solutions may capture
markets regardless of customer relationships. The solutions in these
patterns are only part of an overall business plan that includes
attractive, innovative products.
Rationale: On many projects, developers need
a customer contact to answer questions that arise during
development, and usually, team members simply want a name and a
phone number. Having a person to call is not enough, a relationship
with the customer will give the results developers want.
The relationship with the customer is like a
dance. You take steps, and the customer takes steps in response, and
then you take more steps. You must be focused on the flow of
transactions, on the overall pattern and direction, not merely on
the current product.
Human relationships are fragile and not formed
instantly but develop slowly and evolve over time. The following is
from Selling with Honor [Kohn97]:
In business as in life, it takes a long time to
make friends.
The following is from Dan Behymer, director of
quality systems at a manufacturing facility in Cincinnati
[Behymer97]:
The quality-satisfaction gap is not about
products. It’s about feeling. In a culture where you are
bombarded every day with advertisements, objectives, and
incentives, where someone is always after your hard-earned money,
you just want to know that if you buy their goods, they will care
once the sale is over. We want someone who cares and will take
action. Caring can’t come from a total quality improvement team,
reengineering, just-in-time or any formula, objectives, or
consultants. Customers are human; companies are just collections
of humans.
Impact on Development Process
Most software development follows the
waterfall model, where a fairly long period is spent developing a
requirements specification. When the requirements phase is finished,
most project managers feel that requirements definition is complete.
Milestone meetings might be held with the customer throughout
development to report on progress and deliver documents but it is
not the intent of these meetings to revisit or redefine
requirements. In some cases, no other contact with the customer is
scheduled. Since final release is scheduled for many months later, a
long time could elapse between the initial requirements phase and
the delivery of a completed system. Having only a single
requirements phase means that customers will say, "Here's
everything I could possibly want—because this is my only chance to
get everything on your list!"
Consider for a moment, the complete turnaround
that is happening in today's chaotic development environment.
Requirements are never completely defined up front. It's impossible.
Customers often do not know precisely what they want. They just know
they want it in six months!
The only hope for delivery of a successful
product is to work closely with the customer and examine the
changing marketplace to decide together what the product will
be. This approach gives customers less chance to get
nervous—customers tend to get nervous over time. As customers and
developers learn together, the requirements evolve based on a
clearer understanding of the possible, not the pie-in-the-sky
approach that can result from an attempt to define everything up
front.
When you have something to show the customer,
they're more willing to work with you and better able to say what
they want and will accept. This allows customer input to be well
integrated with product development. Feedback that arrives after the
product is completely finished is more difficult to apply. This
enables the team to work smart, cut unnecessary work and put their
best effort into the things that really matter to the customer.
This kind of development requires different
customer interaction skills. The relationship is more collaborative.
The pattern, It's a Relationship, Not a Sale! says exactly that. The
focus is not on a specific product but on developing a relationship
with the customer. Only in this way, can we be successful in
producing what the customer wants. Applying this pattern leads a
team to have the right perspective for the changing development
process.
As you have read in my article on agile
processes, having an on-site customer or customer representative
is key. The team works closely with the on-site customer to be sure
that questions are correctly answered. Instead of relying on
intuition or what might be fun to develop, the team’s response
follows the business needs, the needs of the customer.
Postmortem Learnings
A retrospective or postmortem at the end of a
project helps an organization learn what worked well and what should
be done differently on succeeding projects. The comments below are
from successful team postmortems and illustrate the use of the
pattern, It's a Relationship, Not a Sale.
"We had demos that didn't work perfectly
but we were able to assure the customer that the product would
work because we spent time establishing a good relationship and
building trust. We talked to the customer every day. This is
especially important early on."
"We had excellent communication with the
customer. We had weekly or biweekly meetings with the customer
where we covered schedule and issues. These meetings kept everyone
aware of issues and made sure we did what we had to do and so did
the customer."
"We had a good relationship and high
degree of trust with the customer. The customer was involved in
system test reviews. We tried to maintain a win/win situation with
our customer."
"We're happy with the way our team handles
marketing issues—we interact directly with the customer. We have
a weekly conference call and since we are a self-directed team, we
deal with the customer on our own. We can get information right
away and the customer can get information from us by calling any
member of the team."
Summary
There seems to be a clear connection between the
software development process and customer interaction. Just as
patterns in a given domain are linked to help a user solve problems
in that domain, so patterns in software development are tied to
organization of the team and the process the team follows and that
includes customer interaction.
References
[Behymer97] Behymer, D., Letter to the editor,
Quality Digest, May 1997, 10.
[Coplien 95] Coplien, J.O., "A Generative
Development-Process Pattern Language," Pattern Languages of
Program Design, J.O. Coplien and D.C. Schmidt, eds., Addison-Wesley,
1995, 184-237.
[Kohn+97] Kohn, L. and J. Saltzman, Selling with
Honor, Berkley Books, 1997.
[McCarthy95] McCarthy, J., #17, "It's a
relationship, not a sale," Dynamics of Software Development,
Microsoft Press, Redmond, WA, 1995, 71-73.
[Rising00] Rising, L., "Customer Interaction
Patterns," Pattern Languages of Program Design 4, Harrison,
N.B., B. Foote, H. Rohnert, eds., Addison-Wesley, 2000, 585-609.
[Whitenack95] Whitenack, B., "RAPPel: A
Requirements-Analysis-Process Pattern Language for Object-Oriented
Development," in Pattern Languages of Program Design, J.O.
Coplien and D.C. Schmidt, eds., Addison-Wesley, 1995, 260-291.
 |
About the Author
http://www.lindarising.org
risingl@acm.org
Linda Rising has a Ph.D. from Arizona
State University in the area of object-based design metrics.
Her background includes university teaching as well as work
in industry in telecommunications, avionics, and strategic
weapons systems. She is the author of numerous articles and
has published three books: Design Patterns in
Communications, The Pattern Almanac 2000, and A Patterns
Handbook. She is currently writing a book with Mary Lynn
Manns: Fearless: Introducing New Ideas into Organizations, to appear in September 2004. |
[
Back to Top ]
|
