As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I know this might be easy for some older andf more experienced VB.Net developers but me as a developer starting out a learning I wanted to know what "Try" and "Catch" is used for.
try, catch, finally, and throw are core to an Exception Handling framework, which is a way to communicate an "exceptional" condition in the code -- most notably errors.
If you are using libraries or frameworks, chances are they have a chance to throw an exception if something fails, and it is your code's responsibility to catch and handle that exception (logging, display to user, try to fix the condition and try again, etc.)
Example (in C#-ish pseudocode, but hopefully you'll get the gist:
try {
doSomething();
}
catch (Exception ex) {
log("doSomething() failed: " + ex.getMessage() + " - " + ex.getStackTrace());
}
You'll see that the exception contains at least three types of useful information:
The type of exception it is.
The message contained in the exception
(set by the code that threw the exception), and
The stack trace,
which traces the call stack to the spot the module, line number, and
error occurred.
Hope that starts you on your path to learning how to handle exceptions in your code.
It is used to catch any exceptions that are thrown. If any statement inside the try block throws an exception, the catch block is executed. If there is a catch block associated to the specific exception thrown, that block is executed. Here is the doc that goes into more detail.
When any exception detected by .net in your try scope, it goes to catch scope, and then you can handle the problem in the catch
Related
Is it possible for the Dispose method of a SqlConnnection object to throw an exception? It's always shown sitting on its own in a finally block outside of the try-catch. And if a using block is equivalent to a try...finally which then calls Dispose, that would also seem to be a case when an exception thrown by Dispose would be problematic.
Technically it can, but it shouldn't:
CA1065: Do not raise exceptions in unexpected locations :
A IDisposable.Dispose method should not throw an exception. Dispose is often called as part of the clean up logic in a finally clause. Therefore, explicitly throwing an exception from Dispose forces the user to add exception handling inside the finally clause.
The Dispose(false) code path should never throw exceptions, because this is almost always called from a finalizer.
Dispose Dos and Don'ts:
Don't throw exceptions in Dispose. Nothing should go wrong with your object calling Dispose.
The moral of the story appears to be that an exception thrown from Dispose is a very bad thing (for some of the reasons you mentioned) and should be handled as high as possible (there's nothing you can do about it, and probably can't recover from it).
In general, a block of code should finish normally if the state of the system will match what the surrounding code expects, and throw an exception if it won't. The the try/catch/finally construct in .NET has a weakness, however, which flows into the IDisposable interface which is designed to work with it (via language constructs like using): a method
void Test()
{
try
{
doSomething();
}
finally
{
doCleanup();
}
}
should only exit normally if both doSomething() and doCleanup() succeed, but if doSomething() throws an exception, the Test() method as a whole should either throw that exception or make it possible to log it. Meeting both requirements would require either that doCleanup() throw an exception of it runs following a successful call to doSomething(), but not following a call which threw an exception, or else that any exception it throws incorporates information about the exception thrown from doSomething().
Unfortunately, there is no convenient way of writing a finally block to vary its behavior based upon the result of the try , nor is there any way for a Dispose() method invoked from a finally to do so. Thus, it is necessary for Dispose implementations to try to guess whether it's more evil to exit normally when an operation fails, or throw an exception which may overwrite an earlier one that held useful information. The latter is somewhat evil, but often not as evil as the former.
For example, consider the pseudocode:
RenameFile(mainFileName, backupFileName);
using(outFile = File.Create(mainFileName);
{
writeDataToNewFile(outFile);
}
DeleteFile(backupFileName);
If something goes wrong while closing the output file and the exception gets propagated out of the using block, the backup file will be left intact and might be recovered later. If the using block were allowed to complete normally despite a failure which prevented the main file from being properly written, the backup file would get deleted, possibly destroying the only copy of some of the data contained therein.
The idea that Dispose shouldn't throw exceptions relates to the fact that there's often no good way to handle exceptions thrown from Dispose. The bigger problem, however, is that there's no good way of handling problems that arise during Dispose without knowing the circumstances under which it is invoked. Throwing an exception from Dispose may be somewhat evil, but still be less evil than allowing it to complete normally in cases where real problems exist.
Why Java creators decided not to throw any error or exception when overflow or underflow hapens considering the fact that such scenarios are usually lethal for any software.
Yes, I know that GOTO is wrong and every time I use it a kitten dies ;) Still one thing makes me curious:
What if I use GOTO in try/catch block
Try
...some code...
Catch
...some code...
GoTo Label1
End Try
...some more code to be skipped if error
Label1:
...rest of code...
Do I understand correctly that the try/catch block will never get closed in the program and it may cause problems? Or not?
There seems to be also some OnError GoTo command but I don't have much experience with it. Maybe my code could be rewriten using it?
Do I understand correctly that the try/catch block will never get closed
No, the try/catch block will be closed because you leave it. It is okay to jump out of the try/catch block.
However, the code should be rewritten to:
Try
...some code...
...some more code to be skipped if error
Catch
...some code...
End Try
...rest of code...
It may be instructive to learn a little about the .NET framework internals:
Exception handling is supported in the CLI through exception objects and protected blocks of code.
(CLI = Common Language Infrastructure)
In the CLI, a method can define a range of CIL instructions that are said to be protected. This is called a try block. It can then associate one or more handlers with that try block. If an exception occurs during execution anywhere within the try block, an exception object is created that describes the problem. The CLI then takes over, transferring control from the point at which the exception was thrown, to the block of code that is willing
to handle that exception.
And this is all done in a declarative manner. So, basically, the Try, Catch, End Try etc items aren't emitted as instructions - the compiler says "if an exception happens in this range of instructions, here are the possible handlers to jump to". And it only consults this information when an exception occurs. So your concern:
the try/catch block will never get closed
isn't valid because the one mechanism for leaving a protected region is... (drum roll please)... to move outside of that range of instructions. It doesn't matter how this is done - it could just be by running out of the end of the protected range, or via a GOTO, or via an exception.
First two quotes are from MS Partition I (section 12.4.2) and MS Partition II (section 19) documents available for download from ECMA C# and Common Language Infrastructure Standards
Section 12.4.2 of Partition I also states:
Protected regions, the type of the associated handler, and the location of the associated handler and (if needed)
user-supplied filter code are described through an Exception Handler Table associated with each method
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I read Apple's recommendation on exception usage and NSError usage:
Also, I read several similar stack overflow questions which discuss whether to use or not exception.
Exception Handeling in iOS
Using exceptions in Objective-C
Objective-C Exceptions
I am trying to figure out pros and cons of usage exception as error notification/handling method in iOS (Frankly, I am no satisfied with Apple's sentence (it says what to do, but it doesn't say why we should do it):
You should reserve the use of exceptions for programming or
unexpected runtime errors such as out-of-bounds collection access,
attempts to mutate immutable objects, sending an invalid message, and
losing the connection to the window server. You usually take care of
these sorts of errors with exceptions when an application is being
created rather than at runtime.
Exception usage pros:
It doesn't require to modify all intermediate code between error generating code and error handling code
It doesn't pollute arguments and return values for methods
Cons:
For all manually managed memory code we will have to be extra careful (we will need to wrap it in autoreleasing objects to make sure that resources are released).
We need to be careful with the border between our code and framework. If our exceptions leave our code, we could be in trouble (because frameworks may manually manage memory)
Did I miss anything? Are there additional cons/pros?
It looks like exceptions should be fine for library like code (when we have quite big amount of tightly packaged code, which doesn't communicate a lot with external systems/frameworks. And it looks like exception are hard to use for the code which actively interacts with other frameworks.
Does your experience prove this theory?
I appreciate any additional info on this subject.
tl;dr Exceptions should be used for fatal/non-recoverable/programmer error(s) only. Attempting to use them a la Java or other exceptions-are-recoverable environments will result in code that is more fragile, harder to maintain, and difficult to refactor while also limiting your ability to leverage system frameworks.
Con: If you use exceptions for flow control and/or recoverable errors in your code, your code will be, by design, different from Apple's design patterns.
End result?
• You can't use Apple's APIs at all in your code unless the border between your code and Apple's always isolates the exception behavior
• Every time your refactor, you'll have to refactor a mass of exception handling code
• Many things that should be trivial will be very complex; for example, you won't be able to put your objects into an enumerable collection and enumerate them without that enumeration -- block, for loop, whatever... -- also having exception processing at the boundaries.
Consider:
NSArray *a = #[yourExceptionfulInstance, yourExceptionfulInstance, yourExceptionfulInstance];
#try {
for(id k in a) { [k doSomething]; }
} #catch(...) {
}
If doSomething might raise, for any reason, the above is violation of the documented design patterns of the framework because you'll be throwing an exception across frames within Apple's framework(s).
That is one mighty big con. Big enough that I can't imagine a set of pros to outweigh it.
What’s the rationale behind the Cocoa exception policy - or why use exceptions only for programmer errors?
I understand that exception used to be rather expensive so one would not want to overuse them. But that changed with the modern runtime and it’s zero-cost exceptions. I also understand that the use of exceptions to do general control flow is not a good idea because it could lead to code that is rather hard to understand.
But why should one use exceptions to signal programmer errors? For that case logging a message followed by abort() should be enough. Why should I write a #catch(...) block to handle a programmer error instead of fixing the actual mistake? I’ve been thinking about this a lot and I haven’t found any reasonable use of an exception for a programmer error.
(As a side note/question: I’ve written a recursive descent parser, and I’m planning on using exceptions in there for handling errors. Seems to be much more reasonable to me than adding an out parameter to every single function in there and manually check for an error everywhere. Of course I’ll catch any exceptions I throw in the top level methods that get called from the outside. Anyone think that’s a bad use for exceptions?)
Update: The real question
Thanks for all the answers so far. They all are true, but they don’t actually answer my question. So I guess I wasn’t really clear about it, sorry for that. So here’s the real question:
Why does Cocoa throw exceptions for programmer errors (or assertions) at all? One isn’t supposed to catch them, and actually writing code that handles a programmer error somewhere down the call stack is not a good idea anyways. Seems to me that exceptions there are a wasted effort. Simply logging the error and calling abort() (which exits the program) should be enough. So what’s the advantage there of actually having an exception thrown?
I understand why exceptions are not generally used and discouraged - most parts of Cocoa are just not exception safe. And that’s not the question here. I hope I made this clear now.
Why should I write a #catch(...) block to handle a programmer error instead of fixing the actual mistake?
In most cases, you wouldn't. In Objective-C, you generally don't handle exceptions. If an exception occurs, it causes a crash, and then you fix the bug -- hopefully you catch this during testing.
Of course, in some cases this doesn't work out. Maybe you do except an exception and you can workaround it, so you catch it. Or there's there rare API that'll throw exceptions instead of using error objects.
To be honest, I very, very rarely use try/catch in my Objective-C code.
As for the rationale, I think it's largely due to Objective-C's C heritage. Back in the early 80s when Objective-C was developed, exceptions were kind of "new" (i.e., not in many mainstream languages yet), and Objective-C catered more to the C tradition of using NULL or an out parameter to signal errors.
Your question explicitly assumes that "one isn’t supposed to catch them." This is incorrect. The programmer isn't expected to catch them under normal circumstances, but that isn't to say that they must never be caught for any purpose.
Example: I'm not sure if it does anymore since it's much less buggy these days, but I know it at least used to be the case that Xcode would catch exceptions and put up a dialog saying, "Such-and-such happened. It doesn't appear to be a critical problem, but you should probably save and restart the program to avoid any trouble in the future."
Why does Cocoa throw exceptions for
programmer errors (or assertions) at
all? One isn’t supposed to catch them,
and actually writing code that handles
a programmer error somewhere down the
call stack is not a good idea anyways
Ah!
Three reasons leap to mind.
One, if you catch an exception more or less at your main run loop you could autosave state to a temporary location, crash, and on restart have a "try to restore from just before the crash, warning: may cause another crash and you should check your data very carefully" dialog/sheet/thingie. Or even just catch the exception and tell the user to do a "Save As", quit and restart.
Two, things like the unit test framework make good use of exceptions to abort the current test (logging a failure), and continuing with the rest of the tests. This lets you see if a change you made has one regression (that happens to index a NSArray out of bounds), or if you have six regressions (one or more of which throw an exception).
Three, maybe when added to ObjC it was intended to handle many kinds of errors with exceptions, and after real world experience the useful scope was determined to be "nearly fatal errors only".
The main reason for avoiding throwing exceptions is that you may accidentally throw them through stack frames that are not exception aware. For instance, if a data source for a table view throws an exception, that is not caught and handled before the delegate method returns control to the table view, it might cause all sorts of trouble as it unwinds the table view's stack frames, side stepping various releases of temporary objects and other resources.
Having said that, I personally like exceptions and use them wherever I think they are the natural thing to do, but with the caveat of never allowing them to propagate to code that is not documented as exception aware.
There are likely a lot of reasons. The "historical reasons" others have covered is sufficient to explain the current state of affairs, but there are other possibilities.
Another possibility is Objective C is not typically a "Resource Acquisition Is Initialization" kind of language (yes this is more a library issue then a language issue, but it is real). So most Objective C code that has an error thrown through it will leave invalid program state (things still locked, over retained objects). All things you could deal with if you were thinking about it, and not all things RAII would magically fix (there is a lot of exception unsafe C++ code out there, and C++ is largely RAII).
As noted above stating that you do handle an exception is free(ish), but actually having one thrown is costly (maybe an order of magnitude or two more costly then an extra parameter and a conditional check). So if your parser (for example) uses them to signal errors in parsing, being given a document with a lot of errors can take a LOT longer to parse then if you had explicit checks for an error parameter.
Personally I like exceptions, and would prefer to throw exceptions from my libraries when things "go wrong", but that isn't the Cocoa way, so I use exceptions to handle programmer errors and an error indication and NSError** for other things. It isn't great, but it makes it so other people can use my libraries without having to learn a new way to write Objective C code.
The modern runtime does not give you zero-cost exceptions, it gives you exceptions that only incur their cost if an exception is thrown.