Re: NSError: why returned directly?
Re: NSError: why returned directly?
- Subject: Re: NSError: why returned directly?
- From: William Bumgarner <email@hidden>
- Date: Wed, 26 Apr 2006 11:23:34 -0700
On Apr 26, 2006, at 11:01 AM, Ondra Cada wrote:
On 26.4.2006, at 17:58, William Bumgarner wrote:
I would very strongly discourage you from using NSExceptions to
indicate anything but programmer error or other internal
assertions. Like it or not, NSError based indication and handling
of runtime errors is the design pattern used throughout AppKit and
Foundation
That's self-evident and I've never ever advocated for something
like reporting runtime errors through NSExceptions.
Yeah -- not really directed at the singular you, but the royal you
[the group]....
OTOH, I see (perhaps mistakenly) a lot of advantages in potential
using @throw for reporting NSErrors (along with, but separately
from, NSExceptions -- just like currently they are returned along
with, but separated from, return values).
Well.... certainly useful, but it is a very slippery slope.
The problem is that there is an impedance mismatch between using
NSError-by-reference and thrown exceptions w/errors to encapsulate
user errors. In particular, any time you cross between your code
and one of the system frameworks, you'll need to make sure your code
does the appropriate conversion, including handling the details of
memory management (never fun in exception handlers).
This leads to more code and more of a maintenance headache as code
changes over time. If you are exposing API to be consumed by other
developers, it will require either refactoring the internals of your
code to use NSError** at the public boundaries or exposing API that
works differently than the rest of Foundation/AppKit/CoreData.
As much as I find it tedious to pass the NSError** through layers of
code, I find that maintaining a codebase consistent with the contract
perpetuated by Foundation/AppKit to be far less work.
b.bum
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden