Re: Core Exception Throwing and Handling

[Phil Muldoon <pmuldoon at redhat dot com>]

Andrew Cagney wrote:
> Phil Muldoon wrote:
> > I thought I'd start this conversation going. It's been an action item 
> > for awhile.
> There are two issues here, and I think it is important to consider 
> each separately:
>
> 1) the first is a core panic, which from the UI point-of-view is 
> asynchronous and fatal
> The only technical point worth debating here is how to get the core to 
> cleanly extract itself from the tasks it;s controlling; and perhaps 
> should the core be started a-new.
Actually I wanted to bring this out too, and debate the mechanism for 
this. Right now all core exceptions are noted in the same way 
(RuntimeExceptions). Is the way forward to only have Runtime exceptions 
for above?
> 2) a failure during a synchronous I/O operation (such as fetch a 
> register) which could either be a table-lookup failure or (rarely) 
> kernel spontaneously disappeared a task
>
> I gather it is the second one that is of concern here.  While more 
> meaningful exceptions would be useful here, for the specific case at 
> hand I think, as Yao pointed out, that the correct thing is to _not_ 
> throw an exception.  A target program having a bogus syscall num 
> should not lead to any exception being thrown - from frysk's 
> point-of-view a bogus syscall num is just as valid as a correct num.
I might be splitting hairs here, buy Yao did not make that suggestion. 
Yao mentioned that:

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

Which I fully agree with. We should not quit on a "negative syscall runtime exception." And it is not the specific case, but all cases in general. I counted roughly 83 different locations in the core that Runtime Exceptions are thrown. I'm fully bought on the idea that checked exceptions are not the best thing since slice bread ;) I'm just musing in a solution that the absence of them leaves behind. So...

I guess what I am interpreting here is, reduce the number of thrown exceptions, only throw them for point 1) and for all of 2) let the core handle them internally (either with null return calls, or something else?)

Regards

Phil


> Andrew