Tag Info

New answers tagged

0

All that is logicaly "necessary" in a programming language are the instructions: assignment a = b subtract a from b goto label test a = 0 if true goto label Any algorithm can be implemented using only the instructions above, all other language constructs are there to make programs easier to write and more understandable to other programmers. See oldie ...


3

As you've apparently already surmised, yes, C++ provides the same capabilities without that mechanism. As such, strictly speaking, the try/finally mechanism is not really necessary. That said, doing without it does impose some requirements on the way the rest of the language is designed. In C++ the same set of actions is embodied in a class' destructor. ...


1

Since this question doesn't specify C++ as a language I'll consider a mix of C++ and Java, since they take a different approach to object destruction, which is getting suggested as one of the alternatives. Reasons you might use a finally block, rather than code after the try-catch block you return early from the try block: Consider this Database db = ...


4

In addition to what others have said, it's also possible for an exception to be thrown inside the catch clause. Consider this: try { throw new SomeException(); } catch { DoSomethingWhichUnexpectedlyThrows(); Cleanup(); } Cleanup(); In this example, the Cleanup() function never runs, because an exception gets thrown in the catch clause and the ...


-1

even if not necessary the 'finally' construct nicely expresses the intent of the developer: 'this code must be run no matter how this block exits'.


7

Some languages offer both constructors and destructors for their objects (e.g. C++ I believe). With these languages you can do most (arguably all) of what is usually done in finally in a destructor. As such - in those languages - a finally clause may be superfluous. In a language without destructors (e.g. Java) it is difficult (maybe even impossible) to ...


41

As others have mentioned, there's no guarantee that code after a try statement will execute unless you catch every possible exception. That said, this: try { mightThrowSpecificException(); } catch (SpecificException e) { handleError(); } finally { cleanUp(); } can be rewritten1 as: try { mightThrowSpecificException(); } catch ...


1

Try finally and try catch are two different things which only share the: "try" keyword. Personally I would have like to see that different. The reason you see them together is because exceptions produce a "jump". And try finally is designed to run code even if programming flow jumps out. Whether that be because of an exception or any other reason. It's a ...


8

What would happen if and exception was thrown that you were not expecting. The try would exit in the middle of it and no catch clause is executed. The finally block is to help with that and ensure that no matter the exception the cleanup will happen.


20

finally blocks are usually used to clear up resources which can help with readability when using multiple return statements: int DoSomething() { try { open_connection(); return get_result(); } catch { return 2; } finally { close_connection(); } } vs int DoSomething() { int result; try { ...


5

Good functional style does not need defensive coding nearly as much as the imperative style. try and catch is not the only control structure which is neglected in Scala (and other functional languages); for and while loops are endangered species and even if...else is used more selectively (although much more effectively, since it returns a value). In the ...


7

It is only good practice to catch a specific exception if it can actually be handled by the catch block. Very often, programmers assume that the fault can be handled at all, close to the point of occurrence. This is often wrong. To understand why, we need to explore what "handling" means. Your second snippet: try { // code implementation } catch ...


-5

I would assume that checking for specific exceptions would have an impact in performance (even if it is minimal) because the program would compare the exception triggered with 3 different values, instead jumping straight to the exception clause. This would increase the number of CPU cycles taken, hence reduce performance. Listing all exceptions does not ...


5

If you expect certain exceptions to be handled at the top level of the program (or close to it), create a specific exception class for them so you can identify them. That way you don't accidentally catch exceptions that arise from program bugs or unrecoverable errors (e.g. out of memory). I don't know the purpose of ApplicationException but Microsoft's ...


1

Exception specifications are not optimal in C++ as also mentioned in the link from Rob K by Herb Sutter, and therefore they are deprecated from the standard in C++11 see ยง 15.4.18. Instead of using the exception specifications, an alternative could be to move them to the function comment block, in this way the information is not entirely lost. Don't ...


2

Pretty much. There's no reason to keep them. I would strip them all out.


2

The part of these exceptions that annoys me most is that it hurts my code coverage. When I'm getting compulsive about coverage, I'll roll up the try / catch that "can never happen" (...or only if I'm using a mutant JVM that somehow forgot to include "US-ASCII") into a class and method that encapsulates that try / catch, and replace the checked exception in ...


1

The answer to your question "where would it be more appropriate to handle the exception" will depend on what your intended semantics are for the getEmployeeByID method. In the .NET Framework, methods that semantically must never throw an exception are prefixed with Try, as in Double.TryParse(). Usually, you pass a string to parse and a ref variable, and ...


1

You may want to have a look at this project; I created it specifically because of the problem of checked exceptions and functional interfaces. With it you can do this instead of writing your custom code: // I don't know the type of f, so it's Foo... final ThrowingConsumer<Foo> consumer = f -> System.out.println(f.get(p)); Since all those ...



Top 50 recent answers are included