Any information in the event should also be available for retrieval by
clients on demand, so the detail would need to be added to
IExecutionDMData too. Unfortunately adding a new method to
ISuspendedDMEvent would break existing implementors, so we'd also need
to create a new interface for the new method (i.e.
ISuspendedDMEvent2).
Since you'll have to implement your own label provider anyway, I
suspect it'll be less trouble to just treat this as your own extension.
Cheers,
Pawel
Warren.Paul@xxxxxxxxx wrote:
Hi Pawel,
Actually, I really just want to
be able to add more detail about an existing member of the enum. It
wouldn't make sense to add exception codes to the enum as these will
vary between architectures and operating systems. You may want to
provide details about other events like what variable and/or address
was read/written for a watchpoint, etc. I was thinking about changing
ISuspendedDMEvent to something like this:
/**
* Indicates that the given thread has suspended.
*/
public interface ISuspendedDMEvent extends
IDMEvent<IExecutionDMContext> {
StateChangeReason getReason();
/**
* Optional method to return more detail about the suspended
event, e.g.
* "Divide by zero exception"
* @return more detail about the suspended event, or null
*/
String getDetails();
}
Let me know what you think.
Thanks,
Warren
I've wondered before whether using an enum for this information would
be limiting, and it sounds like it is :-( At this point, I think the
best backup would be to just add more reasons to the enum as we come
across them. Yes please file a bug for a new enum value.
Cheers,
Pawel
Warren.Paul@xxxxxxxxx wrote:
Currently in DSF you can specify the reason why
a thread was suspended, e.g. breakpoint, watchpoint, exception, etc,
but it's an enum, and the reason text is hard coded. There's no way to
specify more information about the reason, like what type of exception
occurred, or what variable or memory address access caused a watchpoint
to trigger. I can override ExecutionConextContentProvider to have it
do what I want in our debugger, but it seems more natural to extend the
DSF interfaces to support this generically since this is a typical
debugger use case. Should I log a bug and attach a patch for this, or
just override it in our debugger?
Thanks,
Warren
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|