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.