You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As far as we know, the pysftp library remains in a valid state any time it encounters an error. We catch and print errors in the controller, but we then close the application, which can be inconvenient. Wouldn't it be preferable to catch exceptions, print them, and then continue?
If we want to be a bit more cautious, we could specifically catch OSError (which is a synonym of IOError) and possibly one or two other, specific error classes that we know our libraries can raise, and we can continue execution after printing the error messages. However, if we receive any other types of exceptions, we can print and exit.
The text was updated successfully, but these errors were encountered:
It sounds like usability sugar like, it's nice to have but not the biggest deal? work on it if you want/there is nothing pressing. It's a priority 3 with 0 being the highest priority
"wouldn't it be preferable" != "oh god it's all going to die"
As far as we know, the pysftp library remains in a valid state any time it encounters an error. We catch and print errors in the controller, but we then close the application, which can be inconvenient. Wouldn't it be preferable to catch exceptions, print them, and then continue?
If we want to be a bit more cautious, we could specifically catch
OSError
(which is a synonym ofIOError
) and possibly one or two other, specific error classes that we know our libraries can raise, and we can continue execution after printing the error messages. However, if we receive any other types of exceptions, we can print and exit.The text was updated successfully, but these errors were encountered: