Я столкнулся с той же проблемой в «Затмении Марса». Я скачал банки с [ https://oss.jfrog.org/webapp/#/artifacts/browse/tree/General/repo/org/ethereum/ethereumj-core/1.0.0-SNAPSHOT] [1] и заменил его в каталоге.
Я получил ошибку при добавлении ethereum.jar с использованием pom.xml в C: \ Users {machineName} .m2 \ repository \ org \ ethereum \ ethereumj-core \ 1.0.0-SNAPSHOT \ ethereum-core-1.0.0- SNAPSHOT.jar, я добавил сюда загруженный jar (ethereum-core-1.0.0-SNAPSHOT.jar), и проблема была решена.
Документация MSDN для параметра объясняет различные режимы исключений и даже дает примеры кода, чтобы показать разницу между различными режимами. Более того, эта статья может быть интересной, даже несмотря на то, что она довольно старая.
Итог: опция в основном включает или отключает отслеживание продолжительности жизни всех ваших объектов. Такое отслеживание необходимо, потому что в случае исключения необходимо вызвать все надлежащие деструкторы, развернуть стек и выполнить большую очистку. Такое отслеживание требует организационных накладных расходов (= дополнительный код) - от этого можно отказаться, установив для параметра значение «Нет».
Я сам не пробовал,
Компилятор опускает деструкторы и другой код очистки стека, который очищается после объектов C ++, когда они выходят из области видимости в результате исключения.
Другими словами, он не учитывает кучу кода очистки. Это значительно улучшит производительность , но также вызовет серьезное зло, если действительно будет создано исключение. (Если вы мне не верите, рассчитайте время сами.)
На самом деле разница в производительности не является причиной для отключения исключений, за исключением некоторых критических приложений, где вы будете абсолютно обязаны это сделать.
Когда вы говорите «НЕТ» «Включить исключения C ++», то синхронная модель обработки исключений компилятора (/ GX или / EHsc) не выбрана. В этом режиме семантика очистки не будет включена. То есть объект с автоматическим сохранением во фрейме между функцией, выполняющей выброс, и функцией, улавливающей выброс, не будет уничтожен.
Вы можете обратиться к MSDN или FAQ по исключениям Visual C ++ для подробнее об обработке исключений.
class Test
{
public:
Test()
{
printf("Test::constructor");
}
~Test()
{
printf("Test::Destructor");
}
};
int _tmain(int argc, _TCHAR* argv[])
{
int a;
try
{
Test a;
int* p = 0;
*p = 0; // Cause access violation
}
catch (...)
{
printf("Caught access violation");
}
return 0;
}
без обработки исключений, вывод будет следующим:
Test::constructor
Caught access violation
У вас по-прежнему будет доступ к структурированной обработке исключений (SEH), которую можно обрабатывать с помощью __try, __except и __finally.
Обработка исключений C ++ - это просто реализация класса, построенная на основе SEH.
Компилятор также будет пожаловаться, если вы попытаетесь создать экземпляры классов в функции, которая имеет обработчик исключений SEH (жалуется на объекты, требующие раскрутки, например классы), что может быть немного запутанным, но есть способы обойти это.
Что касается стандартного C ++, вы получите неопределенное поведение. Стандарт C ++ не допускает возможность глобального отключения исключений, а некоторые операции стандартной библиотеки определены как выдача исключений при определенных обстоятельствах.
Код, с которым я работал, всегда отключает исключения. Я не встречал проблем, связанных с повреждениями или удалением ресурсов.
Я думал, что исключения обычно плохо подходят для C ++. Взрыв стека, особенно при отсутствии GC, делает все исключения проблемой. А затем дебаты о том, что на самом деле означает «исключительный» по сравнению с просто вероятностью неудач.
Если оператор new
не может выделить память, я считаю, что он вернет NULL
вместо того, чтобы выдавать std :: bad_alloc
исключение.
Если вы сделаете какие-либо обращения к сторонним библиотекам, которые генерируют исключения, это приведет к большим неприятностям.