This is the mail archive of the mailing list for the frysk project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Core Exception Throwing and Handling

I thought I'd start this conversation going. It's been an action item for awhile.

Right now the core throws a lot of RuntimeExceptions. As all java programmers know, a method is not required to declare RuntimeExceptions or any of its sub-classes in a throws clause. This makes exception handing on the method caller optional. It also does not give a heads-up to the method caller that it can expect an exception. With libraries and programs the size of frysk, there are dozens of interfaces into the core. Also RuntimeExceptions are pretty generic. They usually have a message and a trace and not much else.

Here is the problem: the clients of the core have been given an exception. How does that client handle and continue, or handle and quit in an orderly manner? Should all exceptions be explicitly declared so that they can be explicitly handled?

Here is an example:

If ftrace or the UI gets a negative syscall runtime exception should it quit? Like lots of other exceptions it's wrapped in a Runtime exception and thrown.

How can it test if the syscall exception is harmless and can move on?

How can it differentiate between say a double state transition, or and unhanded state to above?

This probably leads in a little to the Checked Exceptions discussion that was happening a few weeks ago.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]