Bugzilla

At the moment, we have `NS_OBJC_BEGIN/END_TRY_IGNORE_BLOCK` and `NS_OBJC_BEGIN/END_TRY_BLOCK_RETURN` macros strewn over much of our Objective C(++) code.

These macros catch Objective C exceptions and then proceed with execution. This means that our code needs to be written with "partial execution" in mind, i.e. we need to think about the program states that we get into if the rest of the function gets skipped due to an exception.

This is an unsafe default.

We should convert all our exception guards to the "fatal" versions. This means that we will crash on all unexpected objective C exceptions.

For "expected" exceptions, we should wrap the appropriate calls in manual, tightly-scoped `@try {} @catch{}` blocks.

This bug tracks converting our code base to the fatal exception guards. We can do it piece by piece, so that we have some time to react to any new crash reports.

At the moment, we have `NS_OBJC_BEGIN/END_TRY_IGNORE_BLOCK` and `NS_OBJC_BEGIN/END_TRY_BLOCK_RETURN` macros strewn over much of our Objective C(++) code.

These macros catch Objective C exceptions and then proceed with execution. This means that our code needs to be written with "partial execution" in mind, i.e. we need to think about the program states that we get into if the rest of the function gets skipped due to an exception.

This is an unsafe default.

We should convert all our exception guards to the "fatal" versions: [`NS_OBJC_BEGIN_TRY_ABORT_BLOCK` + `NS_OBJC_END_TRY_ABORT_BLOCK`](https://searchfox.org/mozilla-central/rev/d504494eab038fd1bbc82eb4191bb334b4de2c8d/xpcom/base/nsObjCExceptions.h#21-29). This means that we will crash on all unexpected objective C exceptions.

For "expected" exceptions, we should wrap the appropriate calls in manual, tightly-scoped `@try {} @catch{}` blocks.

This bug tracks converting our code base to the fatal exception guards. We can do it piece by piece, so that we have some time to react to any new crash reports.

At the moment, we have `NS_OBJC_BEGIN/END_TRY_IGNORE_BLOCK` and `NS_OBJC_BEGIN/END_TRY_BLOCK_RETURN` macros strewn over much of our Objective C(++) code.

These macros catch Objective C exceptions and then proceed with execution. This means that our code needs to be written with "partial execution" in mind, i.e. we need to think about the program states that we get into if the rest of the function gets skipped due to an exception.

This is an unsafe default.

We should convert all our exception guards to the "fatal" versions: [`NS_OBJC_BEGIN_TRY_ABORT_BLOCK` + `NS_OBJC_END_TRY_ABORT_BLOCK`](https://searchfox.org/mozilla-central/rev/d504494eab038fd1bbc82eb4191bb334b4de2c8d/xpcom/base/nsObjCExceptions.h#21-29). This means that we will crash on all unexpected objective C exceptions.

For "expected" exceptions, we should wrap the appropriate calls in manual, tightly-scoped `@try {...} @catch (...) {...}` blocks.

This bug tracks converting our code base to the fatal exception guards. We can do it piece by piece, so that we have some time to react to any new crash reports.

At the moment, we have `NS_OBJC_BEGIN/END_TRY_IGNORE_BLOCK` and `NS_OBJC_BEGIN/END_TRY_BLOCK_RETURN` macros strewn over much of our Objective C(++) code.

These macros catch Objective C exceptions and then proceed with execution. This means that our code needs to be written with "partial execution" in mind, i.e. we need to think about the program states that we get into if the rest of the function gets skipped due to an exception.

This is an unsafe default. It also makes refactoring harder because one has to think about more failure states.
Early "abandonment" (crashing) is ultimately safer and easier to work with.

We should convert all our exception guards to the "fatal" versions: [`NS_OBJC_BEGIN_TRY_ABORT_BLOCK` + `NS_OBJC_END_TRY_ABORT_BLOCK`](https://searchfox.org/mozilla-central/rev/d504494eab038fd1bbc82eb4191bb334b4de2c8d/xpcom/base/nsObjCExceptions.h#21-29). This means that we will crash on all unexpected objective C exceptions.
From the crash reports, we will be able to tell which exceptions can occur in practice, and we can treat them as "expected" exceptions or change our code such that the exceptions are no longer triggered.

For "expected" exceptions, we should wrap the appropriate calls in manual, tightly-scoped `@try {...} @catch (...) {...}` blocks.

This bug tracks converting our code base to the fatal exception guards. We can do it piece by piece, so that we have some time to react to any new crash reports.