@try/ catch problem!

Well, your catch block does nothing. So assuming now that somewhere in the try block an exception is raised, it will be catched but nothing will happen.

 

Why don't you at least put in a simple log message in the catch block, and you will soon find out if you are wrong?

 

First, you're not describing what actually happens. You said "the function does not operate at all", but that's not a description of what happens. Does any of the code in the @try block executed? What would you do to show that this is happening? Maybe an NSLog in the try block?

If the try block is executing, then "the function does not operate at all" is wrong. The function is operating, but you're not seeing the results you expect.

So tell us what you expect to happen, and then tell us what actually happens. When I say that, I mean tell us what is actually being returned from the method. Which might mean that you put an NSLog where you call this method.

Why are we still telling you where to put NSLog statements? Shouldn't these things be obvious by now, considering the last few threads you've started?


Second, it's clear you don't understand how @finally works. It always executes. Think about that. Go re-read the reference doc on try/finally. It always executes. So if that's true, then what should you always expect to see returned by the method? Where would you put an NSLog statement to test whether the @finally is always executing or not?

If you see why @finally is causing that return value, then you should see why it's so important for you to describe what actually happens. If you had said "It's always returning an empty string", then that's a description of what happens. "The function does not operate at all" is not a description, especially if NSLog statements show that it is operating.

 

Remember the things that we discussed last time? NSLog statements? Setting breakpoints in the debugger? Looking at the contents of variables? Learning how to use your tool instead of posting questions?

The other thing: ANY exception in Objective-c code is considered a programmer error. Especially when you move to ARC, Things Will Break when exceptions are thrown. Calling objectAtIndex for an array with no elements is a programmer error and MUST be avoided.

 

Interesting. So this structure is bound to fail because it forces the code to return twice. It looks to me like the whole method needs to be bracketed in a @try so that the exception its design will inevitably generate gets caught.

I have taken to using only one return in any function I write, just creating a variable to be used for the return value (kind of an old Pascal habit, I guess).

 

It doesn't inevitably generate an exception. You should probably read up on it some more. For example, an @try/@finally is legal, with no @catch. As is @try/@catch with no @finally. These have different purposes, so understanding the situations which each block executes is crucial.

That would work here, but it's by no means necessary.