Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Propagate exceptions #923

Merged
merged 21 commits into from Jun 16, 2016
Merged

Propagate exceptions #923

merged 21 commits into from Jun 16, 2016

Conversation

@amolenaar
Copy link
Collaborator

@amolenaar amolenaar commented May 19, 2016

In the code base exceptions are logged (and not propagated) on several occasions or RuntimeExceptions are thrown

This PR cleans up the exceptions, propagate them where possible.

This results in many IOExceptions to be propagated. Is this the right approach?

@fhoeben
Copy link
Collaborator

@fhoeben fhoeben commented Jun 2, 2016

Instead of propagating the IOExceptions as-is, would it be possible to wrap them in a (custom) runtime exception? There's little point in having the exceptions explicit all over your codebase if your just going to propagate them anyway.
RuntimeExceptions allow only the code that actually deals with the exception to have to worry about them. The rest of the code base does not need to be 'polluted' by throws clauses.

Loading

@amolenaar
Copy link
Collaborator Author

@amolenaar amolenaar commented Jun 2, 2016

Well, quite a lot of the methods that throw IOException now are actually dealing with I/O. I ran into trouble with WikiPage, which should not be tied to IOException. I considered creating a custom exception. I try to keep the exceptions as explicit as possible (not hiding stuff with runtime exceptions, see also http://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html).

I suppose we need a custom exception hierarchy then.

Loading

@fhoeben
Copy link
Collaborator

@fhoeben fhoeben commented Jun 2, 2016

Like the page you refer to states there are different views on this topic. But I fully agree with the last paragraph:

Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.

I believe in many places in the current FitNesse codebase there is nothing to be done about an IOException, they will just propagate. So an unchecked (i.e. Runtime) exception is the way to go according to me.

Loading

@amolenaar amolenaar force-pushed the propagate-exceptions branch from a9741f0 to 47393df Jun 4, 2016
output.write(bytes);
output.flush();
} catch (IOException e) {
LOG.log(Level.FINE, format("Could not send data for URL %s: %s (Stop button pressed?)", (request != null ? request.getResource() : ""), e.toString()));
Copy link
Collaborator

@fhoeben fhoeben Jun 5, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see this message in my console quite often. I believe not only when I pressed stop, or navigated away from the page, but I have not been able to determine when it happens.
Stopping a test when this occurs seems like a 'risky' change...

Loading

Copy link
Collaborator Author

@amolenaar amolenaar Jun 5, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is already an issue for this: #834. I expect it has something to do with browsers (most notably Chrome) prefetching data.

Loading

try {
client.done();
client.join();
} catch (InterruptedException | IOException e) {
throw new UnableToStopException("Unable to stop Fit client", e);
Copy link
Collaborator

@fhoeben fhoeben Jun 5, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No Thread.currentThread.interrupt() on InterruptedException?

Loading

@amolenaar amolenaar force-pushed the propagate-exceptions branch from d68ed4f to 63defa4 Jun 8, 2016
@amolenaar amolenaar merged commit 63defa4 into unclebob:master Jun 16, 2016
amolenaar added a commit that referenced this issue Jun 16, 2016
@amolenaar amolenaar added this to the Next Release milestone Jun 16, 2016
@amolenaar amolenaar deleted the propagate-exceptions branch Feb 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants