Maybe I should wait for the patch, from the title, I'm not sure I agree. An ObjC exception is not a recoverable error.

(In reply to Geoffrey Garen from comment #1) > Maybe I should wait for the patch, from the title, I'm not sure I agree. > > An ObjC exception is not a recoverable error. What is the expectation? Why are there places in WebKit we wrap code in @try/@catch?

Some documentation: https://clang.llvm.org/docs/AutomaticReferenceCounting.html#exceptions https://stackoverflow.com/questions/27140891/why-does-try-catch-in-objective-c-cause-memory-leak Potential problems with @catch include: - Undefined behavior if using ARC - Undefined behavior if code below us was not exception-safe (and most code isn't) - It is idiomatic to use NSError * for recoverable errors, and @throw for unrecoverable errors, so the @thrower probably intended to crash I believe existing uses of @try / @catch are legacy workarounds for two kinds of problems: (1) In LegacyWebKit + plug-ins + pre-ARC, it was too easy for a stray ObjC exception out of WebKit's control to terminate the whole browser, and the risk of undefined behavior in @catch was lower. So, we developed an idiom of wrapping any call to arbitrary ObjC in @try / @catch. (2) Sometimes, a specific framework like AppKit or CoreMedia would overzealously @throw an ObjC exception in a specific condition, and it was expedient just to make that go away.

(In reply to Geoffrey Garen from comment #3) > Some documentation: > > https://clang.llvm.org/docs/AutomaticReferenceCounting.html#exceptions > > https://stackoverflow.com/questions/27140891/why-does-try-catch-in-objective- > c-cause-memory-leak > > Potential problems with @catch include: > > - Undefined behavior if using ARC > > - Undefined behavior if code below us was not exception-safe (and most code > isn't) > > - It is idiomatic to use NSError * for recoverable errors, and @throw for > unrecoverable errors, so the @thrower probably intended to crash > > I believe existing uses of @try / @catch are legacy workarounds for two > kinds of problems: > > (1) In LegacyWebKit + plug-ins + pre-ARC, it was too easy for a stray ObjC > exception out of WebKit's control to terminate the whole browser, and the > risk of undefined behavior in @catch was lower. So, we developed an idiom of > wrapping any call to arbitrary ObjC in @try / @catch. > > (2) Sometimes, a specific framework like AppKit or CoreMedia would > overzealously @throw an ObjC exception in a specific condition, and it was > expedient just to make that go away. Seems like we shouldn't do this then, unless we have a stronger desire to in the future, beyond just me seeing an inconsistency in our code base.