Re: Patch: fix up Syscall a bit

[Phil Muldoon <pmuldoon at redhat dot com>]

Tom Tromey wrote:
> > > {
> > > syscall = task.getIsa().syscallByName(name);
> > > }
> > > -    catch (Exception e)
> > > +    catch (TaskException e)
> > > {
> > > -	throw new RuntimeException ("Could not get the name of isa");
> > > +	throw new RuntimeException ("Could not get the name of isa", e);
> > > }
> > > return syscall;
> > >
> > >       
>
> Phil> This exception will stop the event loop for implementing clients (and
> Phil> as the exception is unchecked, very hard to check on the
> Phil> severity). Would it be better to return null in these places instead
> Phil> of completely aborting with a throw?
>
> From what I can tell this only occurs if Task.getIsa() fails.
> But if that fails I think something pretty bad is going on
> here... since it means the code is watching a Task, sees a system
> call, and then the Task fails to return its ISA.  To me that sounds
> like an internal error of some kind, but I don't actually know for
> certain.  Is there a "normal" situation in which this might happen?
>
>   

Oops point taken on that one. I think with the discussion on unchecked 
versus checked over the last several weeks, maybe moving to some kind of 
strategy of the core managing its own minor glitches and notifying the 
client of "really bad things".

What is the criteria for that, you raise a good point. Actually the main 
argument was regarding the negative syscall lookup. I guess the second 
point is, should a syscall lookup on a single Task throw an exception 
that stops the event loop (maybe the task disappeared, and the refresh 
had not caught up with that fact yet?). This touches on the frysk 
modeling the whole system, versus modeling a single Proc. A dodgy task 
should not, imo, scuttle the whole affair.

Anyway, I did not want to derail your patch submission into another 
error/exception thread ;) Other than the worrying about exceptions it 
looks really good.

Regards

Phil