This is the mail archive of the
mailing list for the frysk project.
Re: Core Exception Throwing and Handling
- From: Mark Wielaard <mark at klomp dot org>
- To: Phil Muldoon <pmuldoon at redhat dot com>
- Cc: frysk at sourceware dot org
- Date: Fri, 15 Sep 2006 14:19:29 +0200
- Subject: Re: Core Exception Throwing and Handling
- References: <450A027C.firstname.lastname@example.org>
On Thu, 2006-09-14 at 20:31 -0500, Phil Muldoon wrote:
> 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?
I would say it depends on the documentation of the class/method you are
> 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.
This seems like a bad state, system kaput, no recovery possible
situation. If the method you are calling doesn't document this
issue/exception I think you should regard it as a non-recoverable error
which leaves the underlying system in an unknown, most likely completely
broken state. Don't handle exceptions thrown, but don't documented to
occur. It is like a NullPointerException or NegativeArraySizeException.
If you weren't the person to provide the reference, array or index that
could have caused it (and the documentation should say so), then you
have no way of knowing how to handle it, or whether it is a bug (most
likely) in the thing you are using. So you should quit as if the system
is in a broken/buggy/unrecoverable state.
> How can it test if the syscall exception is harmless and can move on?
The documentation should say so. If it doesn't then there is no way to
know whether or not it is harmless and/or recoverable. So assume it
> How can it differentiate between say a double state transition, or and
> unhanded state to above?
Both a double state transition or an unhandled event for a state (which
I assume you mean) are bugs in the task state machinery and should be
interpreted as the core having died and gone to the great bit bucket