0% found this document useful (0 votes)
212 views10 pages

Recognition and Masking of Non-Atomic Exception Handling: Team Members: D.Abinaya, D.Gowsikhaa, I.Ramya

This document discusses a project to detect and convert non-atomic exception handling methods to atomic methods in Java programs. The project team includes D. Abinaya, D. Gowsikhaa, and I. Ramya. Non-atomic methods can leave objects in an inconsistent state if an exception occurs. The tool analyzes programs through fault injection and compares object states before and after exceptions to find non-atomic methods. It then transforms these methods to take snapshots of object states before calls and roll back if an exception occurs, making the methods robust to exceptions.
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
212 views10 pages

Recognition and Masking of Non-Atomic Exception Handling: Team Members: D.Abinaya, D.Gowsikhaa, I.Ramya

This document discusses a project to detect and convert non-atomic exception handling methods to atomic methods in Java programs. The project team includes D. Abinaya, D. Gowsikhaa, and I. Ramya. Non-atomic methods can leave objects in an inconsistent state if an exception occurs. The tool analyzes programs through fault injection and compares object states before and after exceptions to find non-atomic methods. It then transforms these methods to take snapshots of object states before calls and roll back if an exception occurs, making the methods robust to exceptions.
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 10

Recognition and masking of non-

atomic exception handling

Team members:
D.Abinaya,
D.Gowsikhaa,
I.Ramya.
Project objective
 The main objective of the project is to
detect the various non-atomic
methods in a program and convert
those non-atomic methods into
atomic methods.
Problem statement
 Some programming languages, like
C++ and Java, provide exception
handling support. An exception is
thrown, when a semantic constraint is
violated or when some exceptional
error condition occurs. And then there
is a transfer of control to the point,
where exception is caught.
 An exception that is not caught in a
method is implicitly propagated to the
calling method. The use of exceptions
is a powerful mechanism that
separates functional code from the
error handling code and allows a
clean path for error propagation.
ABSTRACT
Programming languages such as C++
and Java provide sophisticated exception
handling mechanisms to detect and correct
runtime errors. Still exception handling
code must be programmed with care.
Premature termination of a method due to
an exception might leave an object’s state
inconsistent. The objective of this project is
to develop a software, JOptimizer, which
automatically detects and masks the non-
atomic exception handling situations
encountered during program execution.
To discover failure non-atomic methods,
exceptions are injected at runtime into each method
and the calling object’s state before and after the
occurrence of the exception are compared. Methods
that cause an object to enter an inconsistent state are
classified as failure non-atomic. To transform a failure
non-atomic method into a failure atomic method, a
snapshot of the calling object’s state is taken before
each non-atomic method call. If an exception occurs,
a rollback on that object state is done, before
propagating the exception to the user. Thus by
converting non-atomic methods into atomic methods
robustness in software can be achieved.
Methodology of work
 The proposed system intimates the
user about non-atomic methods
present in the user program. It then
transforms the non-atomic methods
in the user program into atomic
methods, on demand. The system
restores object's state back to a
consistent state, in case of Exception,
for non-atomic methods.
System architecture
References
 Amanda Cibele Apolinario Rosa and Eliane Martins (1993) ‘Using
a Reflective Architecture to Validate Object - oriented

Applications by Fault Injection’, IEEE Transactions on Software


Engineering.

 Herbert Schildt ( 2001 ) ‘Java 2: The Complete Reference,Fourth


Edition’, Tata McGraw-Hill Edition.
 Leme et al (2001 ) ‘A Software Fault Injection Pattern System’,
Proc. of the IX Brazilian Symposium on Fault-Tolerant
Computing. Florianópolis, SC, Brasil, pp. 99-113.
 Moraes and Eliane Martins ( 2003 ) ‘Architecture -based Strategy
for Interface Fault Injection’, IEEE Transactions on Software
Engineering, Proceedings of the 2003 International Conference on
Dependable Systems and Networks.
 Pascal Felber et al (2005) ‘Automatic Detection and Masking of
Non - Atomic Exception Handling’, IEEE Transactions on
Software Engineering, Vol. 30, No. 8, pp. 547-559 .
Conclusion
 This system alerts the programmer on
finding the non-atomic methods in the user
program. In many situations, the
programmer can correct the problem by
applying simple modifications to the code.
 This system is capable of automatically
detecting the failure non-atomic methods in
the user program and in most cases turn
them into failure atomic methods.

You might also like