Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [dsdp-mtj-dev] Throwing exceptions within build hooks

Hi guys,

 

It seems to me that an “error” may not be fatal to the whole process, but would be considered fatal to a particular SDK. If an SDK experiences a major issue and cannot continue, it still needs a way to tell the user what happened. How is this accomplished by throwing a CoreException with IStatus.WARNING  or IStatus.INFO?

 

In what circumstances should an SDK throw out an IStatus.ERROR? Is there ANY reason an SDK should be able to stop the whole process?

 

 

Regards,

Jon Dearden

 


From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of David Marques
Sent: Monday, April 27, 2009 8:42 AM
To: Mobile Tools for The Java Platform mailing list
Subject: Re: [dsdp-mtj-dev] Throwing exceptions within build hooks

 

Hi Craig,

    This solution look pretty good for me, I will open a bug to implement that if no one disagrees of course.

Regards,

David Marques

Craig Setera wrote:

OK.  After taking more than 10 seconds to think about this, I believe I have the appropriate solution for handling this. 

 

If you look at CoreException, it wraps around an IStatus instance.  Each IStatus instance has an associated severity.  The only status severities that should cause the build to *fail* would be ERROR.  Warnings, INFO and OK statuses should not stop the build.  Thus, the builder should do something like:

 

- Create an empty list to hold non-fatal statuses from the hooks.

- Call the hooks, catching CoreException instances

- If an exception occurs, the IStatus instance is retrieved from the exception

-- An IStatus may also take the form of a MultiStatus which contains more statuses.  For these, the "worst" severity is the overall severity of the exception

- If the exception status severity is ERROR, the build is stopped and the exception is thrown out from the MTJ builder to the Eclipse framework

- If the exception status severity is WARNING or INFO, the status instances are added to the running list of non-fatal statuses

- If the build completes without an ERROR status and there are non-fatal status instances... a MultiStatus is created to hold those non-fatal instances and a CoreException is thrown from the builder.

- I believe the Eclipse infrastructure will deal correctly with the CoreException that is thrown based on the status values in that exception.

 

I have not implemented this, so there may be some holes in there, but I believe the concept is sound.  It essentially boils down to allowing all hooks to execute unless they declare something is so broken that the entire build should fail.  This puts the responsibility on the hook writer to set the appropriate status severity dependent on what needs to happen.  This also implies we would need to be *very clear* in the documentation.

 

Let me know what you think.

Craig

 

On Apr 24, 2009, at 2:14 PM, Craig Setera wrote:



I wonder if we should be returning IStatus objects instead?

 

On Apr 24, 2009, at 2:07 PM, Jon Dearden wrote:



Hi David,

 

I have two runtimes associated with a project. If I throw a CoreException during one call back, MTJ does not appear to allow the other SDK(s) to have a go. But one SDK should not be able to bring the whole house down.

 

A scenario is that one SDK vendor or user makes an installation error and a critical component is missing in the SDK. The only way the implementer of the hook can respond is to quietly fail (and the user does not know why), or pop up a message (which may interfere with the MTJ UI flow), or throw an exception resulting in the above.

 

Any thoughts on this?

 

 

Regards,

Jon

 

---

Senior Software Developer, Eclipse Tools

Research In Motion

905-629-4746 x15333 / Mobile: 519 500-23167

 

--------------------------------------------------------------------- 
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. _______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev

 

_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev

 

 



 
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
  

 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Back to the top