Xept: a software instrumentation method for exception handling

Vo, Kiem‐Phong; Wang, Y.-M.; Chung, P. Emerald; Huang, Yennun

doi:10.1109/issre.1997.630848

Cited by 16 publications

(12 citation statements)

References 11 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Vo et al describe XEPT, an instrumentation language that can be used to help detect, mask, recover, and propagate exceptions from library functions when source code is not available [32]. APPEND can also be used in situations where The null check columns give counts obtained by instrumenting both the original program and the APPEND-modified program at the bytecode level to record null checks before they are made.…”

Section: Related Workmentioning

confidence: 99%

Changing Java's Semantics for Handling Null Pointer Exceptions

Dobolyi

Weimer

2008

2008 19th International Symposium on Software Reliability Engineering (ISSRE)

View full text Add to dashboard Cite

We envision a world where no exceptions are raised; instead, language semantics are changed so that operations are total functions. Either an operation executes normally or tailored recovery code is applied where exceptions would have been raised. As an initial step and evaluation of this idea, we propose to transform programs so that null pointer dereferences are handled automatically without a large runtime overhead. We increase robustness by replacing code that raises null pointer exceptions with error-handling code, allowing the program to continue execution. Our technique first finds potential null pointer dereferences and then automatically transforms programs to insert null checks and error-handling code. These transformations are guided by composable, context-sensitive recovery policies. Errorhandling code may, for example, create default objects of the appropriate types, or restore data structure invariants. If no null pointers would be dereferenced, the transformed program behaves just as the original.We applied our transformation in experiments involving multiple benchmarks, the Java Standard Library, and externally reported null pointer exceptions. Our technique was able to handle the reported exceptions and allow the programs to continue to do useful work, with an average execution time overhead of less than 1% and an average bytecode space overhead of 22%.

show abstract

Section: Related Workmentioning

confidence: 99%

Changing Java's Semantics for Handling Null Pointer Exceptions

Dobolyi

Weimer

2008

2008 19th International Symposium on Software Reliability Engineering (ISSRE)

View full text Add to dashboard Cite

show abstract

“…The Xept approach [35] provides an generalized framework that illustrates how fine-grain, robust exception handling can be used in critical systems. Xept uses software ªwrappersº around procedure calls as a way to encapsulate error checking and error handling within the context of a readable program.…”

Section: Previous Workmentioning

confidence: 99%

The exception handling effectiveness of POSIX operating systems

Koopman

DeVale

2000

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

AbstractÐOperating systems form a foundation for robust application software, making it important to understand how effective they are at handling exceptional conditions. The Ballista testing system was used to characterize the handling of exceptional input parameter values for up to 233 POSIX functions and system calls on each of 15 widely used operating system (OS) implementations. This identified ways to crash systems with a single call, ways to cause task hangs within OS code, ways to cause abnormal task termination within OS and library code, failures to implement defined POSIX functionality, and failures to report unsuccessful operations. Overall, only 55 percent to 76 percent of the exceptional tests performed generated error codes, depending on the operating system being tested. Approximately 6 percent to 19 percent of tests failed to generate any indication of error despite exceptional inputs. Approximately 1 percent to 3 percent of tests revealed failures to implement defined POSIX functionality for unusual, but specified, situations. Between 18 percent and 33 percent of exceptional tests caused the abnormal termination of an OS system call or library function, and five systems were completely crashed by individual system calls with exceptional parameter values. The most prevalent sources of these robustness failures were illegal pointer values, numeric overflows, and end-of-file overruns. There is significant opportunity for improving exception handling within OS calls and especially within C library functions. However, the role of signals vs. error return codes is both controversial and the source of divergent implementation philosophies, forming a potential barrier to writing portable, robust applications.

show abstract

“…As such, the most closely related work is Xept [36]. The Xept method is a way in which error checking can be encapsulated in a wrapper, reducing flow-of-control disruption and improving modularity.…”

Section: Performing Exception Handlingmentioning

confidence: 99%