This is the mail archive of the
mailing list for the frysk project.
Re: Patch: fix up Syscall a bit
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);
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.