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.
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.
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
On Apr 27, 2009, at 10:17 AM, Jon Dearden
wrote:
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?
---------------------------------------------------------------------
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.
|