If i know that only one function (take in the example) will throw the exception, what could be the correct way, of the following options?
All in the try block:
try
{
while (someCondition)
{
take();
anotherFunction();
}
}
catch(Exceotion e)
{
//some instructions
}
Inside the block only the function that throw the exception:
while (someCondition)
{
try
{
take();
}
catch....
{
//some instructions
}
anotherFunction();
}
I would use the first way because it's clearer, but there is an explicit rule about this?
Thanks!
The two ways do very different things and depending on what you need the code to do, either can be correct.
In the first example, anotherFunction is not called if there was an exception.
In the second example, the exception is being dealt with in the catch block, and anotherFunction will be executed afterwards.
Along the same lines, in the first example, an exception aborts the whole while loop, whereas in the second example it aborts only a single iteration and continues the loop with the next iteration.
Related
So I'm looping over a list of accounts and I wanna break the whole "for loop" for all the accounts in the list, and also at the same time to throw an exception as a certain condition is happening:
accounts.forEach(account -> {
try {
if (isSomethingHappens()) {
String errorMsg = "bla bla, you can't do that cuz condition is happening";
printError(errorMsg);
throw new Exception(errorMsg); // AND I also, in addition to the exception, I wanna break the whole loop here
}
doA();
doB();
} catch (Exception e) {
printError(e);
}
}
Does somebody have any elegant way to do that?
Maybe wrapping it with an exception of my own and on this certain case to catch only it?
Is there a good and known practice for my demand?
I appreciate any help, and tnx a lot!
First thing is - in forEach you don't have break functionality like traditional for loop. so if you need to break for loop use traditional for loop
In Java lambda expression can only throw run-time exception
so one thing you can do this is create CustomeRuntimeException and wrap forEach loop in try catch block
try {
accounts.forEach(account -> {
if (isSomethingHappens()) {
throw new CustomeRuntimeException("bla bla, you can't do that cuz condition is happening");
}
}
} catch (CustomeRuntimeException e) {
printError(e);
}
doA();
doB();
}
by dooing this if isSomethingHappens return ture than CustomeRuntimeException will throw and it will catched by catch block and doA() & doB() method will execute after catch
One good way to do this is to re-raise the error in your inner catch block. This will hand control to the next-outer try/catch. So, put another try/catch block outside of your foreach construct.
The exception occurs and is caught by the innermost try.
The printError() stuff is done.
The exception is re-raised, which kills the forEach.
The try that surrounds the forEach catches the re-raised exception.
We're using PushStreamContent to stream some large lumps with Content-Disposition headers set and the like. As a number of people have discovered, the drawback is what happens when something goes wrong in the streaming?
At the very least, we were trying to get the error logged on our side so someone could follow up.
Recently, I ran into a weird situation. Putting a try/catch around the streaming function worked well enough for errors encountered before you actually started streaming (i.e. errors in sql queries and the like), but if the error occurred later (like in the serialization), the catch block doesn't fire.
Would anyone have any idea why that is?
e.g.
HttpResponseMessage response = new HttpResponseMessage(HttpStatusCode.OK);
try
{
response.Content = new PushStreamContent((stream, content, context) =>
{
using (XmlWriter rWriter = PrepForXmlOutput(stream))
{
rpt.GenerateXmlReport(rWriter, reportParams, true);
}
}, "EventReport", extension);
}
catch (Exception e)
{
// The first step of GenerateXmlReport() is to run the sql;
// if the error happens there, this fires and will log the exception
// if the error happens later, during the result serialization, this does NOT fire
Log.Error(e);
}
return response;
Hate it when I see the answer just after I hit Post.
Try/catch around the outside only covers until I return the HttpResponseMessage. When/where I get the exception depends on how far the inner method gets before that return happens.
The try/catch needed to be on the inner call (the one where all the work happens) to cover the whole lifecycle.
In most programming languages, there is a finally block that can be placed after try or catch block like this :
try {
sensitiveFunction();
} catch (Exception e) {
executedWhenFailed();
} finally {
alwaysExecuted();
}
But we can execute the same code without finally block like that :
try {
sensitiveFunction();
} catch (Exception e) {
executedWhenFailed();
}
alwaysExecuted();
So, why does finally block exist? Anyone have an example that finally block is required ?
Thanks
Even these examples aren't equivalent: if sensitiveFunction() throws something which doesn't extend Exception but Error instead, alwaysExecuted won't be executed without finally (please don't try to "fix" this by catching Throwable).
Or say executedWhenFailed() itself throws an exception: it's quite common to rethrow an exception from a catch block after adding some information. Again, alwaysExecuted() won't be executed in the second snippet.
Or suppose you have return sensitiveFunction(); instead of just a call. Etc. etc.
finally exists so that code can always be run, without regard to if you caught the exception or not.
Sometimes you want to just use try and finally together:
allocate()
try:
do_something_with_allocated()
finally:
deallocate()
In the above example, it lets you 100% confidently clean up a resource that was opened above without regard for any exceptions that may be propagating up.
If you throw a new exception in your catch block, you will eventually (after that exception has been handled) end up in your finally block. But not in the line after your catch.
Just throw an exception in executedWhenFailed, in your first example alwaysExecuted will be executed, in the second it wil not.
The finally block is executed even if there is a return statement in the catch() block.
(Example in JavaScript)
function foo() {
try {
throw "first"
} catch(err){
console.log(err)
return "third"
} finally {
console.log("second") // Called before return in catch block
}
return "Never reached"
}
console.log(foo())
The return statement is being used in void methods to break out of the logic here. The problem is the consumers of the method wouldn’t know whether the logic in the method ran completely or not, when we do this. However my architect and teams don't agree with that. The reason is that the current consumer in this case doesn't care about the outcome.
I think this is coding anti-pattern. It is like eating exception with out bubbling it up. What's everyone's opinion on this?
Existing code:
Private void XXX(final String parameter) {
try {
if (parameter==null){
return;
}
....
}
My version
Private boolean XXX(final String parameter) {
try {
if (parameter==null){
return false;
}
....
return true;
}
In general having multiple returns is not necessarily an anti-pattern. At worst there might be many exit points in the method which can be confusing for developers who are reading the code and perhaps make it harder to maintain...maybe but that is not what you seem to be asking.
The code samples you provided appear to me to both be anti-patterns.
The problem is the consumers of the method wouldn’t know whether the logic in the method ran completely or not, when we do this.
First, that is what Exceptions are for. If there is a problem while executing the code in the method, throw an Exception with an intent revealing type and a good message describing the problem.
The first version of your code:
Private void XXX(final String parameter) {
try {
if (parameter==null){
return;
}
....
}
seemed to return instead of throwing an Exception with an invalid argument.
The second version of the code:
Private boolean XXX(final String parameter) {
try {
if (parameter==null){
return false;
}
....
return true;
}
Seems to return a boolean as an exit code of "worked" or "didn't work". This isn't very helpful because if it didn't work, you don't know why. Also it requires the calling code to check the return value which they might forget to do.
There's nothing wrong with having an explicit return for a void method. However, it is good general practice--if possible--to have just one return from a method (although you can have more than one if logic demands it and you write the code as simply as possible--no blocks--so that the overall flow is not obfuscated).
Should you simply return in the case you cite? It all depends on the requirements. Your customers appear to be the programmers who will call this method. Do they consider a null parameter to be a logic error for the method or do they consider it to be valid?
If it's the former then I suggest you use an annotation (#NotNull) to ensure that parameter is not null. Unfortunately, there are several of these to choose from so you will have to figure out which suits your architecture best.
If you really don't want to use an annotation (and null is considered an error) then throw an exception.
I'm running hadoop job on many input files.
But if one of the files is corrupted the whole job is fails.
How can I make the job to ignore the corrupted file?
maybe write for me some counter/error log but not fail the whole job
It depends on where your job is failing - if a line is corrupt, and somewhere in your map method an Exception is thrown then you should just be able to wrap the body of your map method with a try / catch and just log the error:
protected void map(LongWritable key, Text value, Context context) {
try {
// parse value to a long
int val = Integer.parseInt(value.toString());
// do something with key and val..
} catch (NumberFormatException nfe) {
// log error and continue
}
}
But if the error is thrown by your InputFormat's RecordReader then you'll need to amend the mappers run(..) method - who's default implementation is as follows:
public void run(Context context) {
setup(context);
while (context.nextKeyValue()) {
map(context.getCurrentKey(), context.getCurrentValue(), context);
}
cleanup(context);
}
So you could amend this to try and catch the exception on the context.nextKeyValue() call but you have to be careful on just ignoring any errors thrown by the reader - an IOExeption for example may not be 'skippable' by just ignoring the error.
If you have written your own InputFormat / RecordReader, and you have a specific exception which denotes record failure but will allow you to skip over and continue parsing, then something like this will probably work:
public void run(Context context) {
setup(context);
while (true) {
try {
if (!context.nextKeyValue()) {
break;
} else {
map(context.getCurrentKey(), context.getCurrentValue(), context);
}
} catch (SkippableRecordException sre) {
// log error
}
}
cleanup(context);
}
But just to re-itterate - your RecordReader must be able to recover on error otherwise the above code could send you into an infinite loop.
For your specific case - if you just want to ignore a file upon the first failure then you can update the run method to something much simpler:
public void run(Context context) {
setup(context);
try {
while (context.nextKeyValue()) {
map(context.getCurrentKey(), context.getCurrentValue(), context);
}
cleanup(context);
} catch (Exception e) {
// log error
}
}
Some final words of warning:
You need to make sure that it isn't your mapper code which is causing the exception to be thrown, otherwise you'll be ignoring files for the wrong reason
GZip compressed files which are not GZip compressed will actually fail in the initialization of the record reader - so the above will not catch this type or error (you'll need to write your own record reader implementation). This is true for any file error that is thrown during record reader creation
This is what Failure Traps are used for in cascading:
Whenever an operation fails and throws an exception, if there is an associated trap, the offending Tuple is saved to the resource specified by the trap Tap. This allows the job to continue processing without any data loss.
This will essentially let your job continue and let you check your corrupt files later
If you are somewhat familiar with cascading in your flow definition statement:
new FlowDef().addTrap( String branchName, Tap trap );
Failure Traps
There is also another possible way. You could use mapred.max.map.failures.percent configuration option. Of course this way of solving this problem could also hide some other problems occurring during map phase.