Is there a feature in Xcode to do something like this:
Select a section of source code, chose a refactoring or similar type menu option and the IDE would then wrap the source code in a try/catch block with all the exceptions that could be thrown based on the Class API's used in the selected code?
As a second question, I'm more familar with OO languages where a significant portion of the code is wrapped in try/catch blocks in a production applciation. For example; if an attempt is made to access an array with an invalid index then an "ArrayOutOfBoundsException" would be thrown at runtime, and would be handled by the try/catch block surrounding the code. Is there a similar mechanism is Objective-C? Although I do see that Objective C supports try/catch blocks and expection handling with NSException, I just donot see it used much in the code of the sample projects, or in general which exceptions a given class may throw in the Class References. However I have not yet been thru to many of the class references.
Thank you...
For your first question: No. Consider filing an enhancement request with Apple.
For your second question: It has already been covered by other questions on Stack Overflow like here, here, here, or here. The search box is your friend.
Related
I'm trying to check the stack safety of some very complex code, and would like a way to check the current depth of the call stack and get the result as an integer. I can kind of see how I'd stitch something together, but it involves imports and creating an exception... is there an easier or more elegant way?
For context, I have some very sophisticated, FP-heavy code that I suspect is not stack safe for arbitrary input. I have a lot of general ideas on how to check that, but I don't know that there isn't some black magic in play, so I'd like to check the actual stack depth.
EDIT: Someone suggested this as a duplicate, but:
When I try to use that method, it gives me inconsistent results - sometimes I get what looks like reasonable stack depth, others I get "10" for everything, including a test I wrote to intentionally stack overflow. I'm hoping there's an alternate method available.
Even if it is the best available, the question refers to Java, and it might be easier for future people investigating the Scala situation to find that it is in fact the same without having to ask.
Error handling using the keywords throw, throws, do, try, and catch was introduced in version 2 of Swift. In the relevant chapter of the official Swift documentation the word exception is not used, but it is stated:
Error handling in Swift resembles exception handling in other
languages, with the use of the try, catch and throw keywords. Unlike
exception handling in many languages—including Objective-C—error
handling in Swift does not involve unwinding the call stack, a process
that can be computationally expensive.
So just because the call stack is missing it cannot be called an exception? (Is there a scientific definition for the features an error handling mechanism has to provide to be called as exception?)
I would argue that why it is called error handling has nothing to do with the call stack. This is corroborated by the fact that based on the definitions of both words, the call stack is irrelevant. I believe that the purpose of the quote that you have included in your question is merely to provide a distinction between error-handling in Swift and exception-handling in other languages, disregarding the differences in names.
To identify the distinction in terms of non-swift languages, a common description is that it is an error not to handle an exception. Thus an error and an exception are two unique entities.
Now in Swift, it seems that they have tried to completely get rid of the word "exception" in favor of just using the term error. Thus an error can be dealt with, and if not, the program crashes. This is likely because it is not as important what the actual crash is called, and what is more important is what caused it, in this case an "error".
In terms of usage in the iOS world, I have little experience in this, but I would assume that even though to call it "exception handling" is not technically correct, most Swift programmers would know what you are talking about and probably not correct you (or even think to correct you).
Overall, I think it is mostly a matter of semantics, and not what constitutes an "error" and what constitutes an "exception".
Edit
I should clarify that I mean that the difference between errors and exceptions within iOS/Swift is not just semantics. Exceptions are what are thrown when illegal things happen, and errors can be created to allow you to prevent these messages from being shown/your program crashing. In this respect they are completely different things.
My point is that among different coding languages the term "error" (in Swift) and "exception" (in Java for example) are basically the same, just with different names.
For example, I could try and deal with an error named "ArrayError" (stupid name I know, it's just for an example) where as in Java I could be trying to catch IndexOutOfBoundsException. Both of these objects are both thrown and caught, and thus I am drawing a comparison between the two highlighting the differences in naming conventions in Swift vs other languages.
But no, errors and exceptions are not technically the same thing, even in Swift.
Is there a reason the Eclipse content assits doesn't work in/around lambdas? In a normal case Eclipse usually does this after writing a dot:
Which works just fine like anywhere else. However just a couple of lines later I get nothing:
Both objects are of the same type. Unfortunately I use these all the time as they make everything much faster and I don't understand why it works in one lambda and not the other.
Attempting an explanation (you asked for a reason): parsing lambda expressions in Java is a technical challenge, as the Java grammar was not made for parser generators. Code completion, OTOH, inevitably depends on parsing incomplete code, i.e., heuristics must be used to continue parsing after a syntax error. These two just don't nicely cooperate. As a result in some situations your incomplete code will look like garbage to the compiler and hence content assist is not able to figure out, what would be meaningful proposals.
The applied heuristics are constantly being improved. I recommend trying your examples on a recent milestone build. If the problem still exists, you might help the team by filing a bug providing a code example, and describing your expectations and what actual behavior you observe.
in Chapter 5 Section 3.4 of the rails-3-2.railstutorial it says
Of course, this is essentially a duplicate of the helper in Listing 4.2, but having two independent methods allows us to catch any typos in the base title. This is dubious design, though, and a better (slightly more advanced) approach, which tests the original full_title helper directly, appears in the exercises (Section 5.6).
I did as it said, but i do not understand the mentioned benefit
...having two independent methods allows us to catch any typos in the base title.
The "original" method in application_helper.rb and the test method in spec/support/utilities.rb act exactly the same. So from my point of view it´s a disvantage - there are two places to missspell.
I am new to ruby & rails and having a hard time cause the tutorial covers alot of new stuff, so please bear with me. I would be glad if someone could take some time to help me to understand.
Kind regards,
Stephen
RSpec is a tool for testing.
So it's kind of check list that it "should" be.
If there is a typo one of two methods, the RSpec test will fail, so that you can notice there is something wrong there.
I hope this helps.
How would you define "unwanted code"?
Edit:
IMHO, Any code member with 0 active calling members (checked recursively) is unwanted code. (functions, methods, properties, variables are members)
Here's my definition of unwanted code:
A code that does not execute is a dead weight. (Unless it's a [malicious] payload for your actual code, but that's another story :-))
A code that repeats multiple times is increasing the cost of the product.
A code that cannot be regression tested is increasing the cost of the product as well.
You can either remove such code or refactor it, but you don't want to keep it as it is around.
0 active calls and no possibility of use in near future. And I prefer to never comment out anything in case I need for it later since I use SVN (source control).
Like you said in the other thread, code that is not used anywhere at all is pretty much unwanted. As for how to find it I'd suggest FindBugs or CheckStyle if you were using Java, for example, since these tools check to see if a function is used anywhere and marks it as non-used if it isn't. Very nice for getting rid of unnecessary weight.
Well after shortly thinking about it I came up with these three points:
it can be code that should be refactored
it can be code that is not called any more (leftovers from earlier versions)
it can be code that does not apply to your style-guide and way-of-coding
I bet there is a lot more but, that's how I'd define unwanted code.
In java i'd mark the method or class with #Deprecated.
Any PRIVATE code member with no active calling members (checked recursively). Otherwise you do not know if your code is not used out of your scope analysis.
Some things are already posted but here's another:
Functions that almost do the same thing. (only a small variable change and therefore the whole functions is copy pasted and that variable is changed)
Usually I tell my compiler to be as annoyingly noisy as possible, that picks 60% of stuff that I need to examine. Unused functions that are months old (after checking with the VCS) usually get ousted, unless their author tells me when they'll actually be used. Stuff missing prototypes is also instantly suspect.
I think trying to implement automated house cleaning is like trying to make a USB device that guarantees that you 'safely' play Russian Roulette.
The hardest part to check are components added to the build system, few people notice those and unused kludges are left to gather moss.
Beyond that, I typically WANT the code, I just want its author to refactor it a bit and make their style the same as the rest of the project.
Another helpful tool is doxygen, which does help you (visually) see relations in the source tree.. however, if its set at not extracting static symbols / objects, its not going to be very thorough.