I really don't understand use of finally block...
in try-catch block, Whether we use finally or not we can get same run of our code.
for example what is difference between these code:
try
{
System.out.println(1/0);
}
catch(ArithmeticException e)
{
System.out.println("Error");
}
finally
{
System.out.println("After try-catch");
}
and this:
try
{
System.out.println(1/0);
}
catch(ArithmeticException e)
{
System.out.println("Error");
}
System.out.println("After try-catch");
what is logically difference in output or hierarchy of running codes???
A finally will ALWAYS execute, except in certain cases, such as a System.exit() call, or a thread abruptly exiting.
As always the JLS defines all behaviours
Related
I have few similar methods and there calls as follows :
methodThrowingException() throws NullPointerException, InterruptedException, TimeoutException {
<method logic>
}
Calling class :
try{
methodThrowingExceptions();
<some other logic>
}
catch (NullPointerException npx) {
npx.printStackTrace();
log more details...
}
catch (InterruptedException inx) {
inx.printStackTrace();
log more details...
}
catch (TimeoutException tox) {
tox.printStackTrace();
log more details..
}
How (if) can I put all of these three in one Custom Exception?
Other than (1) is there a way to optimise the code so that I need not write the entire same statements for multiple methods?
Since Java 7, you can use a multi-catch block:
catch (NullPointerException | InterruptedException | TimeoutException e) {
e.printStackTrace();
log more details...
}
That said, you should never catch NullPointerException: that is a bug, and if it happens, the exception should bubble up. You can't reasonably expect a NPE to happen.
In addition, doing the same thing for an InterruptedException as for the other exceptions is also very dubious. When catching an InterruptedException, you should reset the interrupted flag on the current thread, and stop what you're doing ASAP.
At compile (macro) time, calling
Context.parse("a bad expression", somePos)
produces an error that cannot be caught in a try-catch block (Edit: this is wrong, see below). Is there a way to catch this error? Context.parseInlineString() doesn't seem to work either.
Others functions such as Context.typeExpr() have a similar problem.
Edit:
The type of catch was wrong. I did:
try {...}
catch (err:String) {...}
What you have to do:
try {...}
catch (err:Dynamic) {...}
Careful reading of the documentation explains this. This is different than Java for which there is one type of exception per error. In Haxe, most errors are strings, but there are some others like the one here.
The following works for me:
import haxe.macro.*;
class Test {
macro static function test() {
try {
Context.parse("a bad expression", Context.currentPos());
} catch(e:Dynamic) {
trace(e); //Test.hx:8: Missing ;
}
return macro {};
}
static function main() {
test();
}
}
I'm looking to check what type of exception is retruned in the following code snippet.
I'm not sure exactly how to do it though, or if it's even possible.
try {
//SOME LOGIC
} catch (exception ex) {
System.debug(//EXCEPTION TYPE);
}
Would anyone have any suggestions or advice??
try {
//SOME LOGIC
} catch (Exception ex) {
System.err.println(ex.getClass().getName());
}
Few things:
You have posted exception. I assume you meant Exception.
System.debug does not exist.
I have answered your specific question but obviously this is not standard exception handling code. You will instead output the stacktrace, log the exception or rethrow a different one.
Firstly, within your catch block(s), specify the exception. Semantically, types including Exception are not in camel case.
Secondly, you can obtain the exception type through Exception.getClass().getName():
catch (Exception exception) {
System.out.println(exception.getClass().getName());
// exception.printStackTrace();
// throw exception;
}
Specified by:http://docs.oracle.com/javase/7/docs/api/java/lang/Exception.html
After some searching around I found an answer,
try {
//SOME LOGIC
} catch (Exception ex) {
System.debug(ex.getTypeName());
}
The getTypeName() method does the trick nicely.
I apologise for not specifying I was working in Apex in my question.
I am trying my first features with Behat and I am facing the problem I don't know how to implement expected exceptions.
I found the issue https://github.com/Behat/Behat/issues/140 and robocoder is talking about one possible way, which is used by Behat, too. But it seems that they aren't really handling exceptions.
My point is to achieve forced exception handling. I don't want any construct catching all exceptions and forget them.
One possible way would be:
When <player> transfers <transfer> from his account it should fail with <error>
Implementation
try {
...
} catch (\Exception $ex) {
assertEquals($error, $ex->getMessage());
}
I don't like the scenario description. I want to use the then keyword, e.g.
When <player> transfers <transfer> from his account
Then it should fail with error <error>
This description has the disadvantage I need two methods:
method1($arg1, $arg2) {
// Test the transfer
}
method2($arg1, $arg2) {
// Check if the exception is the right one
}
To be able to check in method2 the exception needs to be stored.
The only possible way I see is to use a try/catch and store it to a variable.
Someone else would catch it and do nothing with it. Nobody will notice, when running the tests.
How can I prevent that exceptions are discarded?
Has anybody else a similar scenario implemented?
Thanks for any hints.
EDIT:
Behat context:
playerTransfer($player, $amount) {
$player->transfer($amount);
}
Method from entity class:
transfer($amount) {
if ($this->getWealth() < $amount) {
throw NotEnoughMoney();
}
...
}
Always try to catch method outcome to context class field, for example:
//inside Behat context class method
try {
$this->outcome = $func();
}
catch(\Exception $ex) {
$this->outcome = $ex;
}
Now when expecting exception at next step just check if $this->outcome is instanceof desired exception with message/code.
I think the problem is in your implementation. Do you check if transfer is successful in "When transfers from his account" ? Do you need to check it ?
Failure test:
When <player> transfers <transfer> from his account
Then I should see error <error>
Successful step:
When <player> transfers <transfer> from his account
Then I should see "transfer successful"
Here's how I successfully did it in a project of mine where I had to repeat a few steps till the condition held true:
/**
* #Given /^I execute some conditions$/
*/
public function executeConditions()
{
$flag = 1;
do {
try {
<steps to be executed till the condition holds true>
$flag=1;
} catch (\Exception $ex) {
$flag = 0;
}
}while ($flag>0);
}
I have an if condition which checks for value and the it throws new NumberFormatException
Is there any other way to code this
if (foo)
{
throw new NumberFormatException
}
// ..
catch (NumberFormatException exc)
{
// some msg...
}
If you are doing something such as this:
try
{
// some stuff
if (foo)
{
throw new NumberFormatException();
}
}
catch (NumberFormatException exc)
{
do something;
}
Then sure, you could avoid the exception completely and do the 'do something' part inside the conditional block.
If your aim is to avoid to throw a new exception:
if(foo)
{
//some msg...
} else
{
//do something else
}
Don't throw exceptions if you can handle them in another, more elegant manner. Exceptions are expensive and should only be used for cases where there is something going on beyond your control (e.g. a database server is not responding).
If you are trying to ensure that a value is set, and formatted correctly, you should try to handle failure of these conditions in a more graceful manner. For example...
if(myObject.value != null && Checkformat(myObject.Value)
{
// good to go
}
else
{
// not a good place to be. Prompt the user rather than raise an exception?
}
In Java, you can try parsing a string with regular expressions before trying to convert it to a number.
If you're trying to catch your own exception (why???) you could do this:
try { if (foo) throw new NumberFormatException(); }
catch(NumberFormatexception) {/* ... */}
if you are trying to replace the throwing of an exception with some other error handling mechanism your only option is to return or set an error code - the problem is that you then have to go and ensure it is checked elsewhere.
the exception is best.
If you know the flow that will cause you to throw a NumberFormatException, code to handle that case. You shouldn't use Exception hierarchies as a program flow mechanism.