Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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.
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.
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.
Aha, yep, now I can reproduce.
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.
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.
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...
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.
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.
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?
Oops, meant *implement* it client-side.
Okay, this is starting to sound more doable.
Maybe I can hold onto this bug after all.
*** Bug 5565 has been marked as a duplicate of this bug. ***
Tracking bug #15541.
Fixed with 15541.