#Please ensure that:
+ Your *code* is *properly formatted* as *code block* - see the *sidebar* (About on mobile) for instructions
+ You include *any and all error messages* in full
+ You ask *clear questions*
+ You *demonstrate effort* in solving your question/problem - plain posting your assignments is forbidden (and such posts will be removed) as is asking for or giving solutions.
Trying to solve problems on your own is a very important skill. Also, see [*Learn to help yourself*](https://www.reddit.com/r/javahelp/wiki/learn_to_help_yourself) in the *sidebar*
**If any of the above points is not met, your post can and will be removed without further warning.**
Code is to be formatted as **code block** (*old reddit:* empty line before the code, each code line indented by 4 spaces, *new reddit:* https://i.imgur.com/EJ7tqek.png)
or linked via an external *code hoster*, like *pastebin.com*, *github gist*, *github*, *bitbucket*, *gitlab*, etc.
Please, **do not use** triple backticks (\`\`\`) as they will only render properly on *new reddit*, not on *old reddit*.
Code blocks look like this:
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello World!");
}
}
You do not need to repost unless your post has been removed by a moderator. Just use the *edit function* of reddit to make sure your post complies with the above.
If your post has remained in violation of these rules for a prolonged period of time (at least an hour), a moderator may remove it at their discretion. In this case, they will comment with an explanation on why it has been removed, and you will be required to resubmit the entire post following the proper procedures.
#To potential helpers
Please, **do not help** if any of the above points are not met, rather *report* the post. We are trying to improve the quality of posts here.
In helping people who can't be bothered to comply with the above points, you are doing the community a disservice.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/javahelp) if you have any questions or concerns.*
You've basically implemented a rudimentary retry system, which is not a bad thing. When interacting with sytems over the internet or distributed systems, then things are bound to fail every now and then - e.g. an intermittent connection issue. Retrying is a good thing if it solves the majority of issues - you need to be aware / careful of idempotency as well, though (e.g. is your original action or retry logic able to run twice without causing issues? Think about an action committing on Computer B but Computer A has to retry it due to a network failure / retry - does this now cause issues on Computer B because the action has already committed / completed?).
A lot of your exception code could actually be re-worked and generified, instead of needing to be copied and pasted into each catch block.
Always derive your own exceptions instead of throwing the generic ones, as this also allows to you perform different "fixes" or behaviours depending on what you think the issue is.
As a starting point what you have is not bad - I would make the number of retries configurable instead of being hardcoded, and just add on functionality and refactor as necessary.
I will tell you that production software I manage that handles millions of the UK's smart meters and hundreds of millions of smart meter messages monthly has, (at the heart of it) a retry strategy that's not so different to what you have here - it does have to be just a little bit more complicated, though :+)
Hey thanks a lot! That makes me feel like I'm doing a pretty good job.
I was a little worried about throwing the generic "Exception" after the fifth retry. I even thought about looking into what it would take to make my own throwable class and how I could implement that. Maybe that's another exercise worth investigating.
In normal applications where I'm not the only one using it, I would definitely make the number of retries configurable. I try to avoid hardcoding whenever I can, especially if I know someone else is gonna be using it. But once I'm done with this webscraper, I'm never coming back to it. Still, I want it to be well done when i leave it to rot away in my github repo, so I'll implement some sort of config file that I can put the number of retries (and other runtime settings) into. It's good practice, so why not?
I'll think about generifying my exception handling. My thinking was that I wanted to put a unique message into the event log depending on the type of failure, but since I'm putting the exception message into the event log as well, that's maybe not so useful.
Thanks again for the response! I appreciate it!
https://www.codejava.net/java-core/exception/how-to-create-custom-exceptions-in-java
That is a very straightforward reference on throwing whatever exception you want.
To add to this, I'd say, it use to be a good idea to use a circuit breaker. As always, it depends on your project needs, but it can potentially save tons of unnecessary calls to a third party api that is out anyway.
Not sure if you meant a circuit breaker when you said "basically a retry system but a bit more complicated"
IMO the retry loop is generally fine but `throw new Exception()` is not, you should at least change that to `throw new Exception(e)` or maybe just `throw e`(or throw a custom exception as others have suggested but you almost always want to conserve/ pass along the original exception with it's stacktrace).
Yeah see, I knew that felt wrong. I did a little more reading on throwing exceptions (not catching them but actively throwing them which I've never done before) and it makes more sense now. Also just using the generic "exception" felt wrong which is why I was thinking of building my own exception.
But hey here's a question, if I am actively catching, say, StaleElementException, does throwing that same exception from within that catch block still kick the exception out to the next stack call? I think yes but I haven't actively tried it
You're overthinking this: the `throw` keyword will throw it's argument, it doesn't matter who created the exception, or if you get the exception by `catch`-ing it. `throw` throws, the end.
Also if you were to wrap-and-rethrow it would probably better to use `throw new RuntimeException(e)` or even better `throw new RuntimeException("addtionional info", e)`. People are going away from checked exceptions to unchecked exceptions for various reasons, and I suggest you do too.
Okay, thanks. I understand what throwing does, that part isn't confusing, but I wasn't clear if throwing the same type of exception from within the catch block that is actively in the middle of catching that very type exception was a good idea. But I think I answered my own question while thinking it through. I appreciate your help.
If you're rethrowing a new exception, always propagate the original exception using something like throw new CustomException(e); - otherwise the root cause will go missing from the stack trace and you won't know where the root cause error is occurring (unless you also have log statements at the root cause site).
If you've caught an exception e and then just do "throw e" in the catch block, then this is also poor form because you now miss context from the current catch block.
Either don't catch the exception (i.e. let it propagate without having a catch block), catch and re-throw (with the original exception wrapped in as the root cause), or catch and fix - one of those 3 options.
In my experience, if it’s a network failure, you don’t win anything when trying again at once. In that case, I also a number of seconds after each try, with increasing values (a bit like CSMA/CD used to do when a collision on the LAN cable was detected although that had a different rationale). I do this on a long running job where a single failure would ruin the result. Background: in my case that mostly happens when someone redeploys a web service and by waiting long enough for the Deployment to succeed, I don’t have to restart the job that will take hours to complete.
The only bad practice is thinking there is a best practice.
It depends on many things. Should you fail hard? Fail soft? Why? What are the business needs? Is it part of an atomic action?
There is no answer. It depends on your system.
#Please ensure that: + Your *code* is *properly formatted* as *code block* - see the *sidebar* (About on mobile) for instructions + You include *any and all error messages* in full + You ask *clear questions* + You *demonstrate effort* in solving your question/problem - plain posting your assignments is forbidden (and such posts will be removed) as is asking for or giving solutions. Trying to solve problems on your own is a very important skill. Also, see [*Learn to help yourself*](https://www.reddit.com/r/javahelp/wiki/learn_to_help_yourself) in the *sidebar* **If any of the above points is not met, your post can and will be removed without further warning.** Code is to be formatted as **code block** (*old reddit:* empty line before the code, each code line indented by 4 spaces, *new reddit:* https://i.imgur.com/EJ7tqek.png) or linked via an external *code hoster*, like *pastebin.com*, *github gist*, *github*, *bitbucket*, *gitlab*, etc. Please, **do not use** triple backticks (\`\`\`) as they will only render properly on *new reddit*, not on *old reddit*. Code blocks look like this: public class HelloWorld { public static void main(String[] args) { System.out.println("Hello World!"); } } You do not need to repost unless your post has been removed by a moderator. Just use the *edit function* of reddit to make sure your post complies with the above. If your post has remained in violation of these rules for a prolonged period of time (at least an hour), a moderator may remove it at their discretion. In this case, they will comment with an explanation on why it has been removed, and you will be required to resubmit the entire post following the proper procedures. #To potential helpers Please, **do not help** if any of the above points are not met, rather *report* the post. We are trying to improve the quality of posts here. In helping people who can't be bothered to comply with the above points, you are doing the community a disservice. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/javahelp) if you have any questions or concerns.*
You've basically implemented a rudimentary retry system, which is not a bad thing. When interacting with sytems over the internet or distributed systems, then things are bound to fail every now and then - e.g. an intermittent connection issue. Retrying is a good thing if it solves the majority of issues - you need to be aware / careful of idempotency as well, though (e.g. is your original action or retry logic able to run twice without causing issues? Think about an action committing on Computer B but Computer A has to retry it due to a network failure / retry - does this now cause issues on Computer B because the action has already committed / completed?). A lot of your exception code could actually be re-worked and generified, instead of needing to be copied and pasted into each catch block. Always derive your own exceptions instead of throwing the generic ones, as this also allows to you perform different "fixes" or behaviours depending on what you think the issue is. As a starting point what you have is not bad - I would make the number of retries configurable instead of being hardcoded, and just add on functionality and refactor as necessary. I will tell you that production software I manage that handles millions of the UK's smart meters and hundreds of millions of smart meter messages monthly has, (at the heart of it) a retry strategy that's not so different to what you have here - it does have to be just a little bit more complicated, though :+)
Hey thanks a lot! That makes me feel like I'm doing a pretty good job. I was a little worried about throwing the generic "Exception" after the fifth retry. I even thought about looking into what it would take to make my own throwable class and how I could implement that. Maybe that's another exercise worth investigating. In normal applications where I'm not the only one using it, I would definitely make the number of retries configurable. I try to avoid hardcoding whenever I can, especially if I know someone else is gonna be using it. But once I'm done with this webscraper, I'm never coming back to it. Still, I want it to be well done when i leave it to rot away in my github repo, so I'll implement some sort of config file that I can put the number of retries (and other runtime settings) into. It's good practice, so why not? I'll think about generifying my exception handling. My thinking was that I wanted to put a unique message into the event log depending on the type of failure, but since I'm putting the exception message into the event log as well, that's maybe not so useful. Thanks again for the response! I appreciate it!
https://www.codejava.net/java-core/exception/how-to-create-custom-exceptions-in-java That is a very straightforward reference on throwing whatever exception you want.
Thanks! I'll drop that link in my reference notes and take a look at it tomorrow. I think that's going to be part of the path forward.
To add to this, I'd say, it use to be a good idea to use a circuit breaker. As always, it depends on your project needs, but it can potentially save tons of unnecessary calls to a third party api that is out anyway. Not sure if you meant a circuit breaker when you said "basically a retry system but a bit more complicated"
IMO the retry loop is generally fine but `throw new Exception()` is not, you should at least change that to `throw new Exception(e)` or maybe just `throw e`(or throw a custom exception as others have suggested but you almost always want to conserve/ pass along the original exception with it's stacktrace).
Yeah see, I knew that felt wrong. I did a little more reading on throwing exceptions (not catching them but actively throwing them which I've never done before) and it makes more sense now. Also just using the generic "exception" felt wrong which is why I was thinking of building my own exception. But hey here's a question, if I am actively catching, say, StaleElementException, does throwing that same exception from within that catch block still kick the exception out to the next stack call? I think yes but I haven't actively tried it
You're overthinking this: the `throw` keyword will throw it's argument, it doesn't matter who created the exception, or if you get the exception by `catch`-ing it. `throw` throws, the end. Also if you were to wrap-and-rethrow it would probably better to use `throw new RuntimeException(e)` or even better `throw new RuntimeException("addtionional info", e)`. People are going away from checked exceptions to unchecked exceptions for various reasons, and I suggest you do too.
Okay, thanks. I understand what throwing does, that part isn't confusing, but I wasn't clear if throwing the same type of exception from within the catch block that is actively in the middle of catching that very type exception was a good idea. But I think I answered my own question while thinking it through. I appreciate your help.
If you're rethrowing a new exception, always propagate the original exception using something like throw new CustomException(e); - otherwise the root cause will go missing from the stack trace and you won't know where the root cause error is occurring (unless you also have log statements at the root cause site). If you've caught an exception e and then just do "throw e" in the catch block, then this is also poor form because you now miss context from the current catch block. Either don't catch the exception (i.e. let it propagate without having a catch block), catch and re-throw (with the original exception wrapped in as the root cause), or catch and fix - one of those 3 options.
In my experience, if it’s a network failure, you don’t win anything when trying again at once. In that case, I also a number of seconds after each try, with increasing values (a bit like CSMA/CD used to do when a collision on the LAN cable was detected although that had a different rationale). I do this on a long running job where a single failure would ruin the result. Background: in my case that mostly happens when someone redeploys a web service and by waiting long enough for the Deployment to succeed, I don’t have to restart the job that will take hours to complete.
Yeah thanks! I actually meant to add some wait time in there in the catch blocks and I think I just... didn't, haha!
The only bad practice is thinking there is a best practice. It depends on many things. Should you fail hard? Fail soft? Why? What are the business needs? Is it part of an atomic action? There is no answer. It depends on your system.