Exception handling in a few places in biojava-structure could be improved. I think it is a good idea to apply the practice of "throw early, catch late" (see for instance http://programmers.stackexchange.com/questions/231057/exceptions-why-throw-early-why-catch-late).
So as a very general rule there should be less catching and more throwing forward so that Exceptions are packed together and can be handled by the end-user (i.e. the application that makes use of biojava).
This is also a good read: http://wikijava.org/wiki/10_best_practices_with_Exceptions
Some things that should be avoided in my opinion:
catch (Exception e) especially if deep in the library, it can hide NullPointerExceptions (or similars) and make debugging very difficult
- in tests it's also good to throw exceptions instead of catching them and failing, so that they show as errors and not as failures (of course this depends on the case)
- printing stack traces and re-throwing: the printing of stack traces should also be a responsibility of the final user, so that he/she has full control of verbosity of their output
In any case exception handling is always very difficult, but I think we can try to improve it a bit. This will surely require some changes in interface in cases where more Exceptions need to be thrown, so I'd propose we could include this in next release if there is agreement that we move forward to version 4.
Exception handling in a few places in biojava-structure could be improved. I think it is a good idea to apply the practice of "throw early, catch late" (see for instance http://programmers.stackexchange.com/questions/231057/exceptions-why-throw-early-why-catch-late).
So as a very general rule there should be less catching and more throwing forward so that Exceptions are packed together and can be handled by the end-user (i.e. the application that makes use of biojava).
This is also a good read: http://wikijava.org/wiki/10_best_practices_with_Exceptions
Some things that should be avoided in my opinion:
catch (Exception e)especially if deep in the library, it can hide NullPointerExceptions (or similars) and make debugging very difficultIn any case exception handling is always very difficult, but I think we can try to improve it a bit. This will surely require some changes in interface in cases where more Exceptions need to be thrown, so I'd propose we could include this in next release if there is agreement that we move forward to version 4.