Skip to content

Rethink and unify error handling #73

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

Closed
manuel-mauky opened this issue Jun 5, 2014 · 1 comment
Closed

Rethink and unify error handling #73

manuel-mauky opened this issue Jun 5, 2014 · 1 comment

Comments

@manuel-mauky
Copy link
Collaborator

At the moment the error handling isn't optimal. In some cases we simple log an error message and return null in error cases.

For example, when you have a NullPointerException in one of your initialize methods you only get notified when you have logging configured. The reason is that such exception is encapsulated into an IOException by the FXMLLoader's load method and we are catching IOExceptions in our ViewLoader.

This is only an example. In general we should think about rules on when to (re)throw exceptions and when to just log them.

@manuel-mauky manuel-mauky added this to the 0.3.0 milestone Jun 5, 2014
@manuel-mauky
Copy link
Collaborator Author

In some of the last issues (f.e. #97, #84, #83) we have already changed the exception handling in many cases.
As far as I can tell the last place where no exception is thrown and only a message is logged is when an Exception is thrown in an implicit initialize method for JavaViews. At the moment this exception will be catched and only logged.

I will change this behaviour now.

manuel-mauky added a commit that referenced this issue Jul 30, 2014
…w handed to the user instead of only logging it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant