Exception handling in kernel

[Jim Marino <jm...@myromatours.com>]

Now that we are using absolute URIs for Component names, I have  
removed context names from TuscanyRuntimeException and  
TuscanyException as there is no need to add additional hierarchy  
information when an exception is propagated. This also means we can  
make most exception data final.

Jim


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Exception handling in kernel

[Jim Marino <jm...@myromatours.com>]

> I assume you are thinking of exception chaining for this (using the  
> cause).
>
> I'm OK with that provided we pay careful attention to the ways  
> things get wrapped. For example, there's a tendency to wrap and  
> rethrow just to get a compatible exception and that can result in a  
> confusing chain. We would need to be careful about allowing  
> exceptions to propagate upwards where appropriate and about adding  
> context when we decide instead to wrap.
>
Yep I think there are a bunch of places where this is happening.

> This is really problematic with internal RuntimeExceptions because  
> they are often not declared on the interfaces. I think we need to  
> examine the use of unchecked exceptions and can convert many of  
> them to checked. For example, I don't think any exception raised  
> during deployment should be unchecked.
>
I started to do this a while back and we probably need to continue.  
For some things, e.g. non-recoverable exceptions, I prefer runtime  
exceptions, e.g. exceptions in the JDO and Hibernate 3.0 APIs. For  
thing like deployment, however, I agree with you. One other thing I  
noticed when we were using more unchecked exceptions was that we were  
not properly catching and handling exceptions since they were often  
unchecked. I prefer we use the rule of thumb that things *runtime*  
code needs to react to, which are most things, are checked (for  
exceptions propagated to app code they should be osoa exceptions  
which are unchecked)

> We are also seeing context get lost in error messages because the  
> whole chain is not being printed - I think this may be because some  
> (possibly 3rd party) exceptions are overriding printStackTrace and  
> are not following the chain. I think we need to make sure every  
> exception prints something (albeit not very friendly) when  
> printStackTrace is called - we also need to make sure formatters  
> are present for common user-facing conditions (e.g. bootstrap and  
> deployment).
>
I started to put some formatters for common exceptions a while back.  
We should continue to add more and get them into the standalone  
runtime. In terms of exception handling and hierarchies, we should do  
a thorough cleanup now that the major runtime refactors are in place.

Jim
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Exception handling in kernel

[Jeremy Boynes <jb...@apache.org>]

On Feb 18, 2007, at 9:27 AM, Jim Marino wrote:

>
> On Feb 18, 2007, at 9:23 AM, Jeremy Boynes wrote:
>
>> I think we should leave the context name stuff in there.
>>
>> We don't need to use it for backtracking URIs so that part should  
>> change to just storing the absolute id (assuming it is actually  
>> available).
>>
>> However, the context support is still useful for backtracking  
>> across contexts (for example, for backtracking through a number of  
>> includes).
>>
> For this case, I think we should have that information in specific  
> exception types, e.g. LoaderException. The context stuff was  
> including in the root checked and unchecked exceptions and was  
> being used inconsistently.

I assume you are thinking of exception chaining for this (using the  
cause).

I'm OK with that provided we pay careful attention to the ways things  
get wrapped. For example, there's a tendency to wrap and rethrow just  
to get a compatible exception and that can result in a confusing  
chain. We would need to be careful about allowing exceptions to  
propagate upwards where appropriate and about adding context when we  
decide instead to wrap.

This is really problematic with internal RuntimeExceptions because  
they are often not declared on the interfaces. I think we need to  
examine the use of unchecked exceptions and can convert many of them  
to checked. For example, I don't think any exception raised during  
deployment should be unchecked.

We are also seeing context get lost in error messages because the  
whole chain is not being printed - I think this may be because some  
(possibly 3rd party) exceptions are overriding printStackTrace and  
are not following the chain. I think we need to make sure every  
exception prints something (albeit not very friendly) when  
printStackTrace is called - we also need to make sure formatters are  
present for common user-facing conditions (e.g. bootstrap and  
deployment).

--
Jeremy


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Exception handling in kernel

[Jim Marino <jm...@myromatours.com>]

On Feb 18, 2007, at 9:23 AM, Jeremy Boynes wrote:

> I think we should leave the context name stuff in there.
>
> We don't need to use it for backtracking URIs so that part should  
> change to just storing the absolute id (assuming it is actually  
> available).
>
> However, the context support is still useful for backtracking  
> across contexts (for example, for backtracking through a number of  
> includes).
>
For this case, I think we should have that information in specific  
exception types, e.g. LoaderException. The context stuff was  
including in the root checked and unchecked exceptions and was being  
used inconsistently.

Jim

> --
> Jeremy
>
> On Feb 17, 2007, at 10:27 PM, Jim Marino wrote:
>
>> Now that we are using absolute URIs for Component names, I have  
>> removed context names from TuscanyRuntimeException and  
>> TuscanyException as there is no need to add additional hierarchy  
>> information when an exception is propagated. This also means we  
>> can make most exception data final.
>>
>> Jim
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Exception handling in kernel

[Jeremy Boynes <jb...@apache.org>]

I think we should leave the context name stuff in there.

We don't need to use it for backtracking URIs so that part should  
change to just storing the absolute id (assuming it is actually  
available).

However, the context support is still useful for backtracking across  
contexts (for example, for backtracking through a number of includes).

--
Jeremy

On Feb 17, 2007, at 10:27 PM, Jim Marino wrote:

> Now that we are using absolute URIs for Component names, I have  
> removed context names from TuscanyRuntimeException and  
> TuscanyException as there is no need to add additional hierarchy  
> information when an exception is propagated. This also means we can  
> make most exception data final.
>
> Jim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org