The NetKernel request mechanism provides the capability for requests to return exceptions if they cannot be executed satisfactorily.

Exceptions can be thrown for a number of reasons: application-level exceptions, misconfiguration of the kernel, failed or misconfigured accessors. The NetKernel microkernel provides support for structured exception handling. Exceptions propagate up the request callstack until handled.

Kernel Exceptions

Exceptions may be generated by the kernel during startup when misconfiguration of the deployed modules will be reported. These exceptions are logged in the System Log. This section lists the exceptions that the kernel may throw during runtime.

exception id	description
URI Resolution Failure	A request was made by a module which could not be resolved within its private address space. A request resolution trace is added to the exception to aid tracking down the problem.
No Transreptor Found	A request was made for a resource of a specific data-type (aspect). The resource was sucessfully accessed by the result could not be transreptor to the desired type because no transreptor could be located within the current module or its imports.
Unrecognised Fragment Identifier	A request was made for resource referenced by a URI with a fragment identifier. No Fragmentor could be found to apply the fragment identifier because the combination of fragment identifier structure and the mimetype of the resource could not be matched to a registered Fragmentor.
Deadlock detected	A request has been dispatched but no activity has occured for at least the deadlock period specified in the System Configuration. The request has been interrupted.
Exception during request processing	An exception occured whilst processing this request. A sub-exception will always occur inside.
Error sourcing resource	A resource request resolved to an ffcpl: module resource within a module however no underlying resource could be found or because of a filesystem access error.
Error sinking resource	A resource sink request resolved to an ffcpl: module resource within a module but failed because of a filesystem access error.
External sink denied	A resource sink or delete request resolved to an ffcpl: module resource within a module but failed because it was initiated outside the owning module.
Unsupported Request Type	A request type ouside the supported types was issued on the kernel.
Null result returned	An accessor returned Java null.
Service Unavailable	An external request was rejected due to throttle overload.

Exception Documents

An exception document consists of a root <ex> element with the following elements:

element	description
id	An identifier for the exception type- analogous to a Java exception class name.
message	A specific message, if necessary describing the error.
timestamp	The timestamp that the exception was thrown
originator	The originating kernel component, accessor, transreptor, etc
stack	If relevant a Java stack trace is captured to a depth defined in the System Configuration. Each level in the stack trace is inside a sub <level> element.
requestid	The request which was being executed when the exception occured.
ex	One or more nested causes.

Support for Exceptions

This section gives a quick summary of exception handling capabilities of various technologies.

technology	exception handling capabilities
Accessors	Accessors can be developed with no exception handling and they will simply propagate exceptions to their caller. Alternatively the accessor APIs throw Java exceptions which can be handled in the Java domain.
DPML	DPML has a nested exception handling construct where exceptions can be handled and accessed as XML. A throw accessor is provided to allow the throwing of exceptions.
XRL	XML Resource Linker has support for defining a URI to be requested when an exception is caught. This can be used to provide a reliable catch-all application error page.
HTTP Bridge	The HTTP Bridge can be used to apply a broad exception handling strategy across a whole fulcrum or just specific zones.