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

I concur. Only the SDK provider would know best what the problem is and how to correct it.

 

To answer your first question, I believe this kind of error should be truly exceptional and not seen in the normal course of activity. I would expect to see problems occurring immediately after the installation of a vendor’s SDK and that is where the vendor will want to provide the most help.

 


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

 

How often do you think you might have problems that would throw exceptions?

 

I agree that we don't want to "hide" problems.  I don't want to over-complicate things if this isn't truly going to be an issue.  I can think of two options to make these problems more obvious to the user:

 

1) After the build, if there are caught WARNINGS, we throw up a dialog to let the user know that the error completed with warnings.  If we did that, we would probably want to figure out a way to allow them to not see the dialog for those error types again?  This would be very generic.

 

2) Honor any IStatusHandlers that might be registered for IStatus codes.  If we get an IStatus with a WARNING and we can find a matching IStatusHandler, we invoke it after the build.  That would put the control back in the hands of the hook writer and give them an option to put up their own UI to resolve the issue.

 

I suppose we could even combine #1 and #2, although that might get ugly.  My preference would be #2, because it puts the control back in the hands of the hook writer who presumably knows best how the user might resolve the issue that caused the warning in the first place.

 

Craig

 

On Apr 27, 2009, at 10:30 AM, Jon Dearden wrote:



Yes, that makes sense. I just don’t want to leave the user with a puzzled look on their face.

 


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

 

If you throw an exception with status of WARNING from your SDK provider, you will have stopped doing anything more in your hook.  Thus, it is "fatal" to you at that point.  But, the exception will be caught and logged by the builder so that the user can see something happened.  In theory, we could also attach a warning "Marker" to the Eclipse resource, assuming we actually have one at that point.  If we did that, it would also show up in the problems view.

 

What it boils down to is this:

Error Status == Something really bad that should kill the build completely.  Not normal in this case, but should be allowed for.

Warning Status == Something bad happened, but the rest of the build should continue.  Probably the "normal" error case for hooks

Info Status == Something happened that you would like logged, but otherwise things are ok.  Not likely thrown until the end of your build hook if at all

 

Make sense?

 

On Apr 27, 2009, at 10:17 AM, Jon Dearden wrote:




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

 

---------------------------------------------------------------------
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