Re: Core Exception Throwing and Handling

[Yao Qi <qiyaoltc at cn dot ibm dot com>]

On Thu, Sep 14, 2006 at 08:31:40PM -0500, Phil Muldoon wrote:
> 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.

we could set up a new class SyscallException to handle this, and
replace RuntimeException with SyscallException.

IMO, ftrace or the UI could *not* quit when they get negative syscall
runtime exception, could skip this negative syscall, report or log
something, and continue.

B.T.W, 
If we cache the system call number in SyscallEvenInfo when enter this
system call, and return the cache value when exit this system call,
the negative system call number could be avoided.  I will post
something about this in details in @frysk.

> 
> How can it test if the syscall exception is harmless and can move on?
It is hard to say to what extent syscall exception is harmful, and
there is no such a general rule to determine which syscall exception
is bad, and which syscall exception is worse.

However, in every specific place that could cause a syscall exception,
we could choose different actions against these syscall exceptions,
according to where it is now.

> 
> 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.

It was discussed here,
http://sources.redhat.com/ml/frysk/2006-q3/msg00090.html

> 
> Regards
> 
> 
> Phil
> 

-- 
Yao Qi