Always try to close a port before opening.

[Tamagotono]

This takes care of serial ports being locked open when an error occurs during a run.

[Tamagotono]

Yes, I have tried it many times and it works reliably. I actually took this code from the disconnect method, so I am guessing that the disconnect method is not run when there is an error, so it just aborts with the port still open.

Since I wrapped the close statements inside a "try" and catch all errors and just let them fail silently, it does not seem to do any harm. If the port is open, then it gets closed. If the port is closed, then this code just silently fails and proceeds to open the port as usual. And yes, I did get a "null" error originally, which lead me to add the "try" and "catch" bits.

I am sure there is a more elegant way of doing this (maybe run the disconnect method instead of my code), but I have no experience with Java and have only dabbled in programming a few other languages.

[t-oster]

Ok, so I will keep this in mind and if there are exceptions, which we cannot fix permanentely, I will change the send-job-method to contain a try-catch block on everything, with a finally-block which calls the disconnect method, even if an exception occurs during the try block.

However I'd rather fix the code to not throw any exceptions during normal operation ;). Thanks for your work. I hope you don't mind me closing this request, since it seems somewhat "hacky" to me to just close the port "just in case".

[Tamagotono]

I don't mind at all. It was most definitely a "hack". I did confirm that
when an exception is thrown during a job, the "disconnect" method is never
run. Would calling the "disconnect" method from any of the "Catch" code, be
the proper way of handling the errors? If so, I would be happy to try to
implement that (it should be within my skill level).

Keep in mind that I am trying to help, since I know you are busy. If I am
being more of a hindrance than a help, please say so. This is a great
project and I would like to be of more help than simply telling you what is
broke. :) Are there any other, non-programming, aspects that you need help
with? Let me know what you need and I'll be happy to assist where I can.

On Mon, Aug 3, 2015 at 11:13 PM Thomas Oster notifications@github.com
wrote:

Closed #24 #24.

—
Reply to this email directly or view it on GitHub
#24 (comment).

[t-oster]

Hi, you are welcome to help. The right place would not be the catch, but the finally block, look here: https://docs.oracle.com/javase/tutorial/essential/exceptions/finally.html.
So you would change the sendJob method to contain a try catch finally construct after the connect method, which in the finally block runs the disconnect method and in the catch block just throws the exception again, so it is still cought in the upper visicut handler.

[Tamagotono]

I'll look into that tomorrow. It's nearly 1am here so time to sleep. I will
also do a bunch of testing to see if I can find any other bugs.
Thanks again.
On Aug 4, 2015 12:42 AM, "Thomas Oster" notifications@github.com wrote:

Hi, you are welcome to help. The right place would not be the catch, but
the finally block, look here:
https://docs.oracle.com/javase/tutorial/essential/exceptions/finally.html.
So you would change the sendJob method to contain a try catch finally
construct after the connect method, which in the finally block runs the
disconnect method and in the catch block just throws the exception again,
so it is still cought in the upper visicut handler.

—
Reply to this email directly or view it on GitHub
#24 (comment).