Re: NSError: why returned directly?
Re: NSError: why returned directly?
- Subject: Re: NSError: why returned directly?
- From: Klaus Backert <email@hidden>
- Date: Wed, 26 Apr 2006 17:46:48 +0200
Hi, Ondra,
see below, please.
Am 26.04.2006 um 14:17 schrieb Ondra Cada:
Yup, of course. What I am asking is what were the reasons behind it
been designed this way, since it forces me to adopt some quite
inconvenient and error-prone patterns (using by-ref returns, manual
unrolling stack, details below). That would mean
(a) Most probably, I am overlooking something important, and am
using NSError the wrong way. If so, I am asking in what I err.
(b) Or perhaps I am using it right and others actually use the same
patterns, but the patterns have advantages over the alternate ones
which exception-like design, outlined below, would allow for. If
so, I am asking what do I overlook and what are advantages of the
current NSError patterns;
(c) Or perhaps (with a very small probability, nonetheless not a
zero one) I am perfectly right and the alternate exception-like
patterns would be better, having no (or negligible) drawbacks and
serious advantages. In this case, if there are no drawbacks I am
overlooking, I would at least turn my private frameworks to use
this, to glue the better (if so) behaviour over "plain" Cocoa.
If I understand the Apple documentation correctly, throwing
exceptions on one side and returning NO / nil with an error parameter
on the other side, are used for two different kind of errors:
---
A Note on Errors and Exceptions
...
Exceptions ... are for programming errors, such as an array index
that is out of bounds or an invalid method argument. User-level
errors ... are for runtime errors, such as when a file cannot be
found or a string in a certain encoding cannot be read. Conditions
giving rise to exceptions are due to programming errors; you should
deal with these errors before you ship a product. Runtime errors can
always occur, and you should communicate these (via NSError objects)
to the user in as much detail as they require.
Although exceptions should ideally be taken care of before
deployment, a shipped application can still experience exceptions as
a result of some truly exceptional situation such as "out of memory"
or "boot volume not available". It is best to allow the highest level
of the application - App itself - to deal with these situations.
---
This is just the Apple way of error handling. In my own applications
I have - until now - no difficulty doing it just the Apple way.
Well, Apple just says: We make the distinction between programming
errors and user-level errors; the first one should be handled by
exceptions, and the second one by return-codes and error parameters.
Why that? I still don't know. When I read it the first time, I was
surprised, and it still seems kind of artificial and arbitrary (yes,
computers and programs are always "artificial" and "arbitrary", but
you get the point ;-).
There are different concepts of error handling, which are useful too,
and some are conceptually more evolved, and perhaps more useful. E.g.
if I use exceptions for all kind of errors, then the stack is
unrolled always automatically. For me, this and the reasons you gave
may be enough to migrate to a different error handling concept in the
near future.
(i) make the innermost level simpler, using plain @throw instead of
somewhat error-prone by-ref return ...;
(ii) make the intermediate level *ways* simpler, since it would not
have to cope with errors at all ...;
(iii) make the topmost/gui level simpler and cleaner using separate
error handlers in @catch blocks, instead of number of error-prone
ifs ...;
(iv) it would even make possible to automatically catch and present
errors if the gui level code neglects to do that, which I think is
desirable for simple/test applications ....
Well, doing it the Apple way isn't really difficult in the short run.
But doing it according to a different concept may be better in the
long run.
BTW, my code structure differs apparently from your's, Ondra - may
be, because the overall architecture is a little bit different - but,
of course, I don't know exactly.
For the mailing list: I would appreciate very much, if someone could
explain the rationale behind Apple's decision. It is important for
the Cocoa topic, because a Cocoa application structure depends very
much on the way of error handling.
Let's see.
Greetings
Klaus
_______________________________________________
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