Что случилось с использованием Потока. Аварийное прекращение работы ()
Это зависит, как Вы определяете ООП. С точки зрения подобного Java ООП, где Вы называете методы на объектах, процедурное программирование является в значительной степени тем же. Насколько я могу сказать, что можно эмулировать все принципы ООП (инкапсуляция, абстракция, полиморфизм, наследование) на процедурном языке как C. Доказательство этого , GObject, некоторым расширяют Objective C и много других реализаций языка ООП с помощью C, как cPython. Это сделано при помощи структур и воздействующий на те структуры с помощью функций:
typedef struct {
Object *isa;
String *name;
Date *birthday;
} Person;
Person *Person_new();
String *Person_name(Person *self);
void Person_setName(Person *self, String *newName);
// ...
интерфейсом является очень ООП как. Это действительно не допускает полиморфизм, но это также возможно. Это очень похоже на интерфейс Python, за исключением того, что атрибуты являются отдельными от "методов":
class Person(object):
def __init__(self):
self._name = ""
self._age = datetime.datetime.now()
@property
def name(self):
return self._name
@property
def age(self):
return self._age
я выбрал Python для примера, потому что "сам" является явным, как в примере C. Много языков ООП, как Java, абстрагируют это.
существует также подобное Smalltalk ООП, куда сообщения отправляются в объекты, а не вызывающие методы для объектов. Различие является тонким на первый взгляд, но оно обеспечивает много питания и гибкости. Это может также быть реализовано на процедурных языках, как доказано Objective C.
Объектно-ориентированное программирование является не обязательно типом языка, а скорее парадигмой. Объектно-ориентированные языки, такие как Java, Python, Ruby, и т.д., обеспечивают синтаксический сахар для легкого управления объектами, и это - основное различие между "процедурными языками" и "объектно-ориентированными языками".
Действительно, библиотека или скорее ряд функций, воздействующих на структуру, совпадает с объектом в C++. На самом деле C++ реализован просто тем способом.
7 ответов
В дополнение ко всему Из других хороших ответов здесь позвольте мне добавить, что нет никакой гарантии, что вызов Thread.Abort действительно прервет рассматриваемый поток когда-либо. Можно (хотя и не очень просто) «укрепить» резьбу от прерывания. Если, например, вы прерываете поток, потому что считаете, что он запускает враждебный код, то этот враждебный код может сопротивляться собственному уничтожению.
Если у вас есть длительная операция, включающая код, которым вы не владеете, который должен быть удаленным чисто, правильный способ сделать это - поместить этот код в его собственный процесс , а не в его собственный поток. (И желательно в этом процессе в домене приложения с высокими ограничениями безопасности.) Затем вы можете полностью убить процесс.
Короче говоря, Thread.Abort в лучшем случае указывает на плохой дизайн, возможно, ненадежный и чрезвычайно опасный. Этого следует избегать любой ценой; единственный раз, когда вы должны хотя бы подумать о прерывании потока, - это какой-то код «аварийного отключения», когда вы пытаетесь как можно более аккуратно разорвать домен приложения.
Легче пораниться. Как заявляли другие, это вызывает исключение в коде, которое может произойти в любой момент. Это может быть хорошо, если вы ожидаете этого и кодируете таким образом, чтобы элегантно обрабатывать это исключение в любой момент, но некоторые люди этого не делают:
Monitor.Enter(obj);
// some code - if exception is raised here, then the lock isn't released
Monitor.Exit(obj)
IDisposable someCriticalResource = GetResource();
// some code - if exception is raised here, then the object isn't disposed
someCriticalResource.Dispose();
Кроме того, если вы работаете со многими людьми в команде, если у вас нет хороших обзоров кода, вы не можете гарантировать качество кода, с которым вы будете работать. Следовательно, будет хорошей идеей проповедовать "no Thread.Abort ()", чем заставлять людей не забывать писать код, устойчивый к исключениям, возникающим где угодно внутри этого кода.
Короче. Любой объект IDisposable не может быть удален. Любой заблокированный объект не может быть разблокирован. Все, что должно быть выполнено на 100%, никогда не будет сделано.
When you call Thread.Abort() on another thread a ThreadAbortException is injected in the flow of that thread. If you're lucky the code will handled this well and abort in a well defined state. The problem is that you have no way to figure out if you will be lucky in every case, so if you prefer safe over sorry calling Thread.Abort on other threads is not a good idea.
Because if you know that the thread is in some safe state in which it can be aborted, surely you can arrange better communication and have the thread exit cleanly.
The thread could have taken a lock and be in the middle of changing some shared state, and the Thread.Abort will undo the lock and leave the shared state corrupted.
Thread.Abort неконтролируемым образом останавливает ваш поток. thread.Abort вызовет исключение, которое приведет к немедленной остановке вашего потока.
Что в этом не так: в большинстве случаев вы хотите корректно остановить выполняемую вами операцию. Например, если вы выполняете операцию ACID, вы можете захотеть завершить текущую операцию перед завершением потока, чтобы ваша система оставалась в стабильном состоянии.
Thread.Abort вызывает исключение в целевом потоке. Тем временем целевой поток может выполнять некоторые важные операции, и возникновение исключения может нарушить состояние вашего приложения.