Как я должен обработать исключения при использовании SwingWorker?

Очень сильно зависит от типа ошибок, которые могут возникнуть в результате фонового задания. Если задание в doInBackground выдает исключение, оно будет распространено на метод done как вложенное исключение ExecutionException. В этом случае лучше всего обрабатывать вложенное исключение, а не само ExecutionException.

Например: если рабочий поток выдает исключение, указывающее, что соединение с базой данных потеряно, вы, вероятно, захотите восстановить соединение и перезапустите работу. Если выполняемая работа зависит от какого-либо ресурса, который, как оказывается, уже используется, было бы неплохо предложить использовать повтор или отменить выбор. Если выброшенное исключение не имеет никаких последствий для пользователя, просто зарегистрируйте ошибку и продолжайте.

Из того, что я помню, я считаю, что InterruptedException не будет проблемой здесь, так как вы делаете вызов метода get в метод done, поскольку InterruptedException будет выброшено только в том случае, если вызов get прерван во время ожидания завершения фонового задания. В случае непредвиденного события, подобного этому, вы, вероятно, захотите отобразить сообщение об ошибке и выйти из приложения.

поскольку InterruptedException будет выброшено, только если вызов get прерван во время ожидания завершения фонового задания. В случае непредвиденного события, подобного этому, вы, вероятно, захотите отобразить сообщение об ошибке и выйти из приложения.

поскольку InterruptedException будет выброшено, только если вызов get прерван во время ожидания завершения фонового задания. В случае непредвиденного события, подобного этому, вы, вероятно, захотите отобразить сообщение об ошибке и выйти из приложения.

Это такой же вопрос интерфейса, как и вопрос обработки ошибок. Многие приложения добавляют небольшую таблицу со списком запущенных фоновых заданий. Исключение в одном из них может высветить строку таблицы, которая вызвала ошибку, или сделать что-то столь же разрушительное, как и выдать предупреждение. Это зависит от серьезности исключения. Я думаю, что более сложный вопрос, на который вам, вероятно, придется ответить, состоит в том, сколько потенциально различных типов исключений мы говорим и какова их относительная серьезность. серьезные ошибки, и все остальное, просто записывают происшествие, пока оно а) не блокирует дальнейшую работу пользователя или б) пользователь не закрывает документ / окно,

Предположим, что это приложение с графическим интерфейсом, возможно, вы захотите предоставить визуальную обратную связь о сбое операции при исключении.

Полагаю, вы не получите много таких вопросов с C #. Вам необходимо понять, что такое исключение, и правильно с ним справиться (что обычно позволяет ему продвинуться дальше вверх по стеку).

InterruptedException - Выдается, когда поток прерывается (посредством Thread.interrupt ) при ожидании (примерно). Почему вы хотите, чтобы поток прерывался? Обычно вы хотите, чтобы поток остановил свою работу - сбросил состояние прерывания и завершил работу. Например, плагин будет прерывать потоки апплета, если они будут продолжаться гораздо дольше после того, как апплет должен исчезнуть. Тем не менее, в этом случае, если done вызывается правильно, вам вообще не следует ждать. Следовательно, было бы целесообразно обернуть исключение в IllegalStateException (и, вероятно, в документации API это должно быть указано). Это действительно плохой API. Режим publish / process , вероятно, имеет больше смысла.

ExecutionException - Вам нужно иметь дело с упакованным исключением. Если вы не ожидаете особого типа исключения, оберните его в непроверенное исключение.

Как правило, я бы предложил провести четкое разделение между тем, что происходит на EDT, и тем, что происходит на EDT. Поэтому избегайте SwingWorker в производственном коде.

Если вы не ожидаете особого типа исключения, оберните его в непроверенное исключение.

Как правило, я бы предложил провести четкое разделение между тем, что происходит на EDT, и тем, что происходит на EDT. Поэтому избегайте SwingWorker в производственном коде.

Если вы не ожидаете особого типа исключения, оберните его в непроверенное исключение.

Как правило, я бы предложил провести четкое разделение между тем, что происходит на EDT, и тем, что происходит на EDT. Поэтому избегайте SwingWorker в производственном коде.

Я бы порекомендовал, чтобы ошибка распространялась вплоть до места начала действия.

Например, если пользователь нажимает кнопку для извлечения данных из данных -источник. Если возникает проблема, будь то учетная ошибка, сетевая ошибка, ошибка базы данных или что-то еще, для вас было бы неуместно иметь логику в этом рабочем потоке, чтобы попытаться решить ее прямо там.

Но если вы позволите ему распространиться туда, где была запущена задача, оттуда вы можете предпринять соответствующие исправления ошибок, такие как повторное появление диалогового окна учетных данных, отображение диалогового окна «повторить попытку» или даже сообщение об ошибке.