Bug 204 - Catchpoint should have option not to catch the exception's subclasses
Summary: Catchpoint should have option not to catch the exception's subclasses
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Debugger ()
Version: 2.6 RC 1
Hardware: Macintosh Mac OS
: Low enhancement
Target Milestone: ---
Assignee: Marius Ungureanu
URL:
: 5565 ()
Depends on: 15541
Blocks:
  Show dependency tree
 
Reported: 2011-08-05 15:25 UTC by Dean Cleaver
Modified: 2013-11-23 09:26 UTC (History)
6 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Dean Cleaver 2011-08-05 15:25:45 UTC
I open my project in MonoDevelop (MonoTouch project), select to stop on all exceptions except System.Threading.ThreadAbortException, but when I run the project it still stops on ThreadAbortExceptions.
Comment 1 Jeffrey Stedfast 2011-08-23 12:36:23 UTC
Which version of MonoDevelop is this? Do you have a test case? I'm not able to reproduce this in MonoDevelop 2.6RC2 (you can download RC1 from http://monodevelop.com/Downloads - running that should prompt to update to RC2 which wasn't pushed to the download site because RC2 is only available for Mac), but I might be (probably am) doing something wrong.

I wrote up a simple test iPhone program which calls Thread.CurrentThread.Abort().

If MonoDevelop's Run -> Exceptions... -> "Stop on Exceptions" list includes ThreadAbortException, then MD stops on that ex, otherwise it doesn't and the app just goes down right after it launches.
Comment 2 Dean Cleaver 2011-08-23 12:38:12 UTC
Try the other way - add every exception except ThreadAbortException and see if it stops - in my case it does.

I will try it with RC2 and MonoTouch 4.1 and see if it still happens to me.
Comment 3 Jeffrey Stedfast 2011-08-23 12:43:00 UTC
Aha, yep, now I can reproduce.
Comment 4 Jeffrey Stedfast 2011-08-23 15:58:15 UTC
The problem is that System.Exception is the base exception type for all other exceptions, so if you add that type to the list of types to stop for, it will implicitly also stop for System.Threading.ThreadAbortException

I suppose we should keep this open as a "feature request" to make this a little more obvious (don't feel bad, it wasn't immediately obvious to me either).

Perhaps moving base exception types to the "stop on these exceptions" list should pull over all their subclasses as well? That might be enough to make things a little clearer and is the simplest solution I can think of.
Comment 5 Dean Cleaver 2011-08-23 16:02:00 UTC
Is it not possible to exclude it if it really is a ThreadAbortException even though it's also a System.Exception? I mean... I might want to stop on other System.Exception exceptions, but not on a ThreadAbortException.

I think there really needs to be check on the specific exception, and if you don't want to stop on that, don't stop. If I select to stop on "System.Exception" I personally wouldn't expect it to stop on ThreadAbordException, even though it's a subclass.
Comment 6 Mikayla Hutchinson [MSFT] 2011-08-23 16:11:49 UTC
Well, I can see why you'd expect it to work that way, because that's how VS works. And, as you say, there may be cases where you want to catch an exact exception type and not its subclasses.

However, the way SDB does it has a couple of advantages - it's the way that C# "catch" works, and it allows you to catch exceptions when you don't know the exact subclass.

Ideally we could find a way to support both, but that UI for that would be challenging...
Comment 7 Dean Cleaver 2011-08-23 16:36:05 UTC
Sorry Michael - what's SDB? Not familiar with that and the acronym doesn't ring a bell.

If the UI was a tree view, it could be done. Checking "System.Exception" would catch all below it (would automatically turn them on) but you can then selectively turn off individual types. Or conversly, you can turn on individual types. Thinking about it, I think that's how VS.Net does it.
Comment 8 Mikayla Hutchinson [MSFT] 2011-08-23 16:47:05 UTC
Sorry, I forgot the acronym wasn't well-known outside the Mono debugger/runtime community. SDB is the Mono Soft Debugger, which lives inside the Mono runtime. MonoDevelop send commands to it over TCP. I don't recall offhand whether the catchpoint requests that MD sends to SDB have an option for subclasses or not - if not, this request would require changes in the runtime.

I checked VS, it has a treeview organized by namespace, not inheritance. But your suggestion makes more sense. We could also use a button to allow adding unknown exceptions by name, like VS has.
Comment 9 Mikayla Hutchinson [MSFT] 2011-08-23 17:17:24 UTC
Ah, on second thoughts, that's not true, we could eliminate it client-side like we do for conditional breakpoints - i.e. when it breaks, evaluate conditions, and if it doesn't satify the conditions, carry on without actually showing it in the UI. 

On that note, conditional catchpoints would be pretty neat, maybe the "add custom exception" button could add those instead of just adding an exception name?
Comment 10 Mikayla Hutchinson [MSFT] 2011-08-23 17:18:07 UTC
Oops, meant *implement* it client-side.
Comment 11 Jeffrey Stedfast 2011-08-23 17:21:47 UTC
Okay, this is starting to sound more doable.

Maybe I can hold onto this bug after all.
Comment 12 Mikayla Hutchinson [MSFT] 2012-06-07 14:18:24 UTC
*** Bug 5565 has been marked as a duplicate of this bug. ***
Comment 13 Marius Ungureanu 2013-10-21 10:11:29 UTC
Tracking bug #15541.
Comment 14 Marius Ungureanu 2013-11-23 09:26:24 UTC
Fixed with 15541.