Exception handling with NSURL
Hi all,
I'm trying to verify a string is a valid URL with the following :
- (void)controlTextDidChange:(NSNotification *)notification
{
NS_DURING
{
NSURL *storeUrl = [NSURL URLWithString:[url stringValue]];
[ok setEnabled:(storeUrl != nil)];
}
NS_HANDLER
{
NSLog([localException name]);
[ok setEnabled:NO];
}
NS_ENDHANDLER
}
When I enter an URL of the form http://user:[EMAIL PROTECTED], an exception is
raised (see below) when starting to enter the password because NSURL is
expecting a numeric port (as in http://host:port). The thing is, the
exception isn't catched by NS_HANDLER (NSLog is never called) and the
application coredumps when I enter another caracter.
NSException: 0x8357318 NAME:NSGenericException REASON:illegal
character in port part STACK:({pointer = 0xb78847be;}, {pointer =
0xb78846f6;}, {pointer = 0xb793e50f;}, {pointer = 0xb793dc1c;},
{pointer = 0xb793d65d;}, {pointer = 0x805e07f;}, {pointer =
0xb78bb181;}, {pointer = 0xb78bb708;}, {pointer = 0xb7c25d88;},
{pointer = 0xb7d1a37a;}, {pointer = 0xb78bb181;}, {pointer =
0xb78bb708;}, {pointer = 0xb78bb5bd;}, {pointer = 0xb7d8e7ab;},
{pointer = 0xb7d8d0bc;}, {pointer = 0xb7c6ac34;}, {pointer =
0xb7c6a8b4;}, {pointer = 0xb7cc128c;}, {pointer = 0xb7d974c2;},
{pointer = 0xb7d45ab2;}, {pointer = 0xb7bc4f4a;}, {pointer =
0xb7bc476b;}, {pointer = 0xb7bc4306;}, {pointer = 0x805deb8;},
{pointer = 0x805f741;}, {pointer = 0x805d61a;}, {pointer =
0xb72e3437;}, {pointer = 0xb7975496;}, {pointer = 0xb7975865;},
{pointer = 0xb7bc571a;}, {pointer = 0xb7c26431;}, {pointer =
0xb7bfca65;}, {pointer = 0xb7bf68b0;}, {pointer = 0xb7c2687b;},
{pointer = 0xb7bf2555;}, {pointer = 0xb7d45ab2;}, {pointer =
0xb7bc4f4a;}, {pointer = 0xb7bc3b38;}, {pointer = 0xb7ba6151;},
{pointer = 0x80670ca;}, {pointer = 0xb75f4050;}, {pointer =
0x804b2f1;})
Am I doing something wrong ?
Thanks,
Philippe
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Exception handling with NSURL
On 2007-12-06 08:51:29 + Philippe Roussel [EMAIL PROTECTED]
wrote:
Hi all,
I'm trying to verify a string is a valid URL with the following :
- (void)controlTextDidChange:(NSNotification *)notification
{
NS_DURING
{
NSURL *storeUrl = [NSURL URLWithString:[url stringValue]];
[ok setEnabled:(storeUrl != nil)];
}
NS_HANDLER
{
NSLog([localException name]);
[ok setEnabled:NO];
}
NS_ENDHANDLER
}
When I enter an URL of the form http://user:[EMAIL PROTECTED], an exception is
raised (see below) when starting to enter the password because NSURL
is
expecting a numeric port (as in http://host:port). The thing is, the
exception isn't catched by NS_HANDLER (NSLog is never called) and the
application coredumps when I enter another caracter.
NSException: 0x8357318 NAME:NSGenericException REASON:illegal
character in port part
snip
Am I doing something wrong ?
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:[EMAIL PROTECTED]' 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.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Exception handling with NSURL
Le jeudi 06 décembre 2007 à 09:32 +, 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:[EMAIL PROTECTED]' 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:[EMAIL PROTECTED]/ but when parsing philou: NSURL thinks it's a hostname followed by a port and is expecting a numeric value. My code used to function (NSURL URLWithString returning nil with a non valid string) until I updated to trunk yesterday or two days ago. I did an update 10 minutes ago and got a modification on NSException.m. Now the exception only logs NSException: 0x84c4e88 NAME:NSGenericException REASON:illegal character in port part INFO:(nil) instead of the previous big blob but the problem remains. Philippe ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Exception handling with NSURL
On 2007-12-06 09:51:35 + Philippe Roussel [EMAIL PROTECTED] wrote: Le jeudi 06 décembre 2007 à 09:32 +, 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:[EMAIL PROTECTED]' 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:[EMAIL PROTECTED]/ 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? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Exception handling with NSURL
Le jeudi 06 décembre 2007 à 10:59 +, Richard Frith-Macdonald a écrit : On 2007-12-06 09:51:35 + Philippe Roussel [EMAIL PROTECTED] wrote: Well, I have to disagree : see NSURL.m line 837. I want to type http://philou:[EMAIL PROTECTED]/ 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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Exception handling with NSURL
On 2007-12-06 12:30:54 + Philippe Roussel [EMAIL PROTECTED] wrote: Le jeudi 06 décembre 2007 à 10:59 +, Richard Frith-Macdonald a écrit : On 2007-12-06 09:51:35 + Philippe Roussel [EMAIL PROTECTED] wrote: Well, I have to disagree : see NSURL.m line 837. I want to type http://philou:[EMAIL PROTECTED]/ 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. Well it does ... unless the program crashes first :-) 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 ...looks like it's crashing while trying to find the callstack return addresses. 1. Could you please let me know what signal is causing the crash ... this code has a signal handler to trap segmentation violations caused by a known bug in gcc, but maybe the gcc function to provide return addresses can crash in ways other than a segmentation violation. 2. Could you also try updating from svn ... I just recently added a check to try to limit the number of return addresses we look up to 2 less than the reported number of stack frames, in the hope of avoiding encountering the bug in gcc's __builtin_return_address() function altogether. It may be that this will have fixed your problem. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Exception handling with NSURL
Le jeudi 06 décembre 2007 à 12:43 +, Richard Frith-Macdonald a écrit : Well it does ... unless the program crashes first :-) :) Thanks ...looks like it's crashing while trying to find the callstack return addresses. 1. Could you please let me know what signal is causing the crash ... this code has a signal handler to trap segmentation violations caused by a known bug in gcc, but maybe the gcc function to provide return addresses can crash in ways other than a segmentation violation. gdb tells me : Program received signal SIGSEGV, Segmentation fault. 2. Could you also try updating from svn ... I just recently added a check to try to limit the number of return addresses we look up to 2 less than the reported number of stack frames, in the hope of avoiding encountering the bug in gcc's __builtin_return_address() function altogether. It may be that this will have fixed your problem. Yep, I did an update and it works perfectly now ! Thanks a lot Richard, Philippe ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
