You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Ramkumar Ramalingam (JIRA)" <tu...@ws.apache.org> on 2008/05/28 13:03:45 UTC

[jira] Assigned: (TUSCANY-2347) Removing the exception throws from the processors

     [ https://issues.apache.org/jira/browse/TUSCANY-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ramkumar Ramalingam reassigned TUSCANY-2347:
--------------------------------------------

    Assignee: Ramkumar Ramalingam

> Removing the exception throws from the processors
> -------------------------------------------------
>
>                 Key: TUSCANY-2347
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-2347
>             Project: Tuscany
>          Issue Type: Bug
>          Components: Java SCA Core Runtime
>    Affects Versions: Java-SCA-Next
>         Environment: Windows XP,
>            Reporter: Ramkumar Ramalingam
>            Assignee: Ramkumar Ramalingam
>             Fix For: Java-SCA-Next
>
>
> After introducing the monitors in various part of the code (especially in the processors), while the runtime reads and resolves the contribution. Now we are trying to remove the exception that are being thrown from these modules. As a first step we are removing the exceptions that are safe to remove, by leaving the critical exceptions like
> a) IOException
> b) XMLStreamException
> c) PriviledegedActionException
> d) and ParseConfigurationExceptions
> As a second step, we will also be dealing with the above said exception once we have a detailed discussion as how to handle them.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Re: [jira] Assigned: (TUSCANY-2347) Removing the exception throws from the processors

Posted by Ramkumar R <ra...@gmail.com>.
Hi Mike,
Thanks for raising this, I believe we need more detailed discussion on this
topic with the community and its important that we all agree upon. Simon has
started a new thread in the ML to discuss about this and here is the link to
same...

http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200805.mbox/%3cc0c051b50805290042x32b495a8pec3cf8e163958870@mail.gmail.com%3e

You can find more detailed discussion about this topic happening
here. Thanks.


On 5/28/08, Mike Edwards <mi...@gmail.com> wrote:
>
> Ramkumar,
>
> Is this such a wise move??
>
> What is the point of allowing processing to continue if the model is
> actually broken in some way?
>
> I would agree that there may be some exceptions that can be removed and
> replaced by the logging of messages, but is it really wise to allow the
> creation of a model that is broken in some important features?
>
>
> Yours,  Mike.
>
> Ramkumar Ramalingam (JIRA) wrote:
>
>>     [
>> https://issues.apache.org/jira/browse/TUSCANY-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>>
>> Ramkumar Ramalingam reassigned TUSCANY-2347:
>> --------------------------------------------
>>
>>    Assignee: Ramkumar Ramalingam
>>
>> Removing the exception throws from the processors
>>> -------------------------------------------------
>>>
>>>                Key: TUSCANY-2347
>>>                URL: https://issues.apache.org/jira/browse/TUSCANY-2347
>>>            Project: Tuscany
>>>         Issue Type: Bug
>>>         Components: Java SCA Core Runtime
>>>   Affects Versions: Java-SCA-Next
>>>        Environment: Windows XP,
>>>           Reporter: Ramkumar Ramalingam
>>>           Assignee: Ramkumar Ramalingam
>>>            Fix For: Java-SCA-Next
>>>
>>>
>>> After introducing the monitors in various part of the code (especially in
>>> the processors), while the runtime reads and resolves the contribution. Now
>>> we are trying to remove the exception that are being thrown from these
>>> modules. As a first step we are removing the exceptions that are safe to
>>> remove, by leaving the critical exceptions like
>>> a) IOException
>>> b) XMLStreamException
>>> c) PriviledegedActionException
>>> d) and ParseConfigurationExceptions
>>> As a second step, we will also be dealing with the above said exception
>>> once we have a detailed discussion as how to handle them.
>>>
>>
>>
>


-- 
Thanks & Regards,
Ramkumar Ramalingam

Re: [jira] Assigned: (TUSCANY-2347) Removing the exception throws from the processors

Posted by Mike Edwards <mi...@gmail.com>.
Ramkumar,

Is this such a wise move??

What is the point of allowing processing to continue if the model is actually broken in some way?

I would agree that there may be some exceptions that can be removed and replaced by the logging of 
messages, but is it really wise to allow the creation of a model that is broken in some important 
features?


Yours,  Mike.

Ramkumar Ramalingam (JIRA) wrote:
>      [ https://issues.apache.org/jira/browse/TUSCANY-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
> 
> Ramkumar Ramalingam reassigned TUSCANY-2347:
> --------------------------------------------
> 
>     Assignee: Ramkumar Ramalingam
> 
>> Removing the exception throws from the processors
>> -------------------------------------------------
>>
>>                 Key: TUSCANY-2347
>>                 URL: https://issues.apache.org/jira/browse/TUSCANY-2347
>>             Project: Tuscany
>>          Issue Type: Bug
>>          Components: Java SCA Core Runtime
>>    Affects Versions: Java-SCA-Next
>>         Environment: Windows XP,
>>            Reporter: Ramkumar Ramalingam
>>            Assignee: Ramkumar Ramalingam
>>             Fix For: Java-SCA-Next
>>
>>
>> After introducing the monitors in various part of the code (especially in the processors), while the runtime reads and resolves the contribution. Now we are trying to remove the exception that are being thrown from these modules. As a first step we are removing the exceptions that are safe to remove, by leaving the critical exceptions like
>> a) IOException
>> b) XMLStreamException
>> c) PriviledegedActionException
>> d) and ParseConfigurationExceptions
>> As a second step, we will also be dealing with the above said exception once we have a detailed discussion as how to handle them.
>