[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Exception handling with NSURL
From: |
Philippe Roussel |
Subject: |
Re: Exception handling with NSURL |
Date: |
Thu, 06 Dec 2007 13:30:54 +0100 |
Le jeudi 06 décembre 2007 à 10:59 +0000, Richard Frith-Macdonald a
écrit :
> On 2007-12-06 09:51:35 +0000 Philippe Roussel <address@hidden> wrote:
> > Well, I have to disagree : see NSURL.m line 837. I want to type
> > http://philou:address@hidden/ but when parsing philou: NSURL thinks it's
> > a hostname followed by a port and is expecting a numeric value.
>
> My thought was ... Line 837 of NSURL.m is only reached when checking the port
> part of the URL, and since there is no port part in your example string, it
> can only be reached from parsing a different URL string.
>
> However, I just realised that you are probably actually talking about
> validating a whole set of URLs as you add a character at a time to the length
> ... 'h', then 'ht' then 'htt' then 'http' then 'http:' and so on.
> When you get to 'http://philou:' the code will be assuming that 'philou' is a
> host name because there is no '@' sign present to tell it that it's actually
> a username and password followed by a host. It therefore assumes that what
> comes after the colon is a port (and it's correct to do so, because that's
> what the RFCs tell us).
Yes, sorry I wasn't clear enough. I'm using this to enable/disable the
"Ok" button of a dialog for each modificaton in a TextField. I just
didn't find another (easy) way to know if a String is a valid url.
I know http://philou: isn't valid and I would like URLWithString: to
return nil as documented.
> > My code used to function (NSURL URLWithString returning nil with a non
> > valid string) until I updated to trunk yesterday or two days ago.
>
> PS. -initWithString:relativeToURL: should only be exiting with an exception
> if you passed it a nil argument. All the other error checking just results
> in a nil value returned. This somewhat inconsistent behavior is copying the
> MacOS-X implementation behavior (I don't believe an initialisation method
> should ever raise an exception). I've modified the logging to refrain from
> printing the diagnostics unless debug is explicitly turtned on.
>
> Anyway, I can't see why any of this should cause a coredump ... perhaps you
> could print a stack trace in gdb to show where/why your app is dumping?
Here it is (URLWithString is called with @"http://philou:c") :
#0 0xb7924c3d in GSPrivateStackAddresses () at NSDebug.m:1145
#1 0xb7938c09 in -[NSException raise] (self=0x857e8c0, _cmd=0xb7b6c548)
at NSException.m:817
#2 0xb793876e in +[NSException raise:format:arguments:]
(self=0xb7b6c340, _cmd=0xb7b6c530, name=0xb7b6c0e4, format=0xb7b9b11c,
argList=0xbfb7a150 "�z9\b\020O3\bH[L\b") at NSException.m:760
#3 0xb79386a6 in +[NSException raise:format:] (self=0xb7b6c340,
_cmd=0xb7b9b5d0, name=0xb7b6c0e4, format=0xb7b9b11c) at
NSException.m:746
#4 0xb79f26c1 in -[NSURL initWithString:relativeToURL:]
(self=0x85197d8, _cmd=0xb7b9b600, aUrlString=0x84c5b48, aBaseUrl=0x0) at
NSURL.m:850
#5 0xb79f1bec in -[NSURL initWithString:] (self=0x85197d8,
_cmd=0xb7b9b5f8, aUrlString=0x84c5b48) at NSURL.m:619
#6 0xb79f162d in +[NSURL URLWithString:] (self=0xb7b9b580,
_cmd=0x8077300, aUrlString=0x84c5b48) at NSURL.m:509
#7 0x0805e3fc in -[iCalStoreDialog controlTextDidChange:]
(self=0x847fc10, _cmd=0xb7f29d08, notification=0x849a598) at
iCalStore.m:62
#8 0xb796f151 in -[NSNotificationCenter _postAndRelease:]
(self=0x80bbe40, _cmd=0xb7b7af08, notification=0x849a598) at
NSNotificationCenter.m:1067
#9 0xb796f6d8 in -[NSNotificationCenter
postNotificationName:object:userInfo:] (self=0x80bbe40, _cmd=0xb7ec94a8,
name=0xb7f46470,
object=0x845d180, info=0x82df438) at NSNotificationCenter.m:1126
#10 0xb7cd9da8 in -[NSControl textDidChange:] (self=0x845d180,
_cmd=0xb7f29df8, aNotification=0x856cc08) at NSControl.m:567
[snip]
It could be something wrong in my code but I haven't changed it in a
long time and it used to work fine.
Thanks,
Philippe