gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Exception handling with NSURL


From: Richard Frith-Macdonald
Subject: Re: Exception handling with NSURL
Date: Thu, 06 Dec 2007 10:59:17 +0000
User-agent: GNUMail (Version 1.2.0)

On 2007-12-06 09:51:35 +0000 Philippe Roussel <address@hidden> wrote:

> Le jeudi 06 décembre 2007 à 09:32 +0000, Richard Frith-Macdonald a
> écrit :
>> My guess is that you are misinterpreting what's happening.
>> 
>> Probably the reason the NSLog() in the exception handler is not called is 
>> because the handler is not called because the exception is not ocurring in 
>> this piece of code.  The exception message 'illegal character in port part' 
>> does not correspond to a URL for the form 'http://user:address@hidden' 
>> because 
>> such a URL has no port part, so it's presumably being raised because some 
>> otyher URL used elsewhere in the program has a port part containing an 
>> illegal character.
> 
> 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).

> 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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]