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]

Re: Core Exception Throwing and Handling

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?)




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