Re: ObjC error messages
Re: ObjC error messages
- Subject: Re: ObjC error messages
- From: Marcel Weiher <email@hidden>
- Date: Thu, 14 Feb 2002 16:10:20 +0100
On Thursday, February 14, 2002, at 03:24 PM, Malte Tancred wrote:
On thursday, february 14, 2002, at 03:00 , Marcel Weiher wrote:
This is really just the default behavior for unrecognized messages,
and it seems quite reasonable that the default is to print a message,
as this is an exceptional situation that (in its unhandled state) is
comparable to a type-error that would prevent compilation in a strict
statically-typed language (and produce an error message).
I agree that some sort of logging should occurr if the exception
isn't handled.
DNU isn't an exception. It is a message that is sent by the runtime
whose default implementation just happens to raise an exception, just
like it also happens to log an error.
But I still argue that it should be handled the way
all other uncaught exceptions are handled, ie through the top level
execption handler.
DNU isn't an exception, it is a message sent by the runtime whose
default implementation raises an exception. It would be a different
issues if the runtime actually raised an exception. It doesn't.
Exceptions in Objective-C are an add-on that is not part of the basic
runtime.
In the case where I actually handle such an error (by catching
the exception that is in fact raised), shouldn't I be the one
deciding whether to log or not?
Exactly. Your object decides how to handle the message.
One could look at it this way: if I decide to handle a possible
exception then it won't be, in a sense, an exception anymore. :-)
Exactly, if you decide to handle the message that is sent, then it won't
even raise an exception. For example, Higher Order Messaging uses
DNU-handling (forwardInvocation:, to be precise) in its implementation.
So does NSProxy.
(until I decide otherwise and reraise the exception or raise
another one).
Yes, you can send different messages in your DNU handler, or none. You
can also log messages or even raise an exception.
You have several options for handling this error yourself.
1. override -doesNotRecognizeSelector: either only in your own
objects or globablly in a category
2. override -forwardInvcation: in order to handle situations in
which you don't actually consider it an error
In my opinion this would be a 'fix' to an inconsistency in the
design of Apple's frameworks.
You are misunderstanding the design.
I suggest the inconsistency is corrected.
It isn't inconistent.
It's not a big deal
Exactly. It is an even smaller deal (just the default implementation of
a method that can be overriden)...
as there are ways to work around the (minor)
problem, but that workarounds are availble doesn't make a correction
unnecessary, right?
It only looks like a workaround to a problem if you misunderstand how
DNU works, for example by assuming that it is exception-based... ;-)
Marcel
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.