Я хочу протестировать свое аварийное сообщение о сбое приложения в поле, преднамеренно связав его с сбоем, когда пользователь выполнит конкретное действие, которое реальный пользователь вряд ли сделает случайно.
Но какой хороший надежный способ сделать приложение аварийным, что не создает предупреждение во время компиляции?
Изменить: Обратите внимание, что многие, казалось бы, очевидные ответы на этот вопрос приводят к исключениям, которые попадают под Cocoa и, следовательно, не приводят к сбою приложения.
в Objective-C используйте C напрямую, чтобы вызвать плохой доступ
strcpy(0, "bla");
Примечание: в то время как это работает в любой системе, которую я знаю - в будущей версии среды выполнения C или компиляторе это больше не может привести к сбою. см. Неверное поведение указателя undefined в Objective-C?)
(в быстром случае вам придется перейти на objC, чтобы это сделать)
Мой текущий любимый:
assert(! "crashing on purpose to test <insert your reason here>");
Классика:
kill( getpid(), SIGABRT );
И некоторые pr0n:
*(long*)0 = 0xB16B00B5;
Все они генерируют сбои, полученные в моем инструменте отчетов о сбоях.
Поскольку мы все используем Clang для iOS, это достаточно надёжно:
__builtin_trap();
Это имеет то преимущество, что оно предназначено именно для этой цели, поэтому оно не должно генерировать никаких предупреждений или ошибок компилятора.
abort(); вызывает ненормальное завершение... Это сбой.
Самый популярный - непризнанная авария селектора:
NSObject *object = [[NSObject alloc] init];
[object performSelector:@selector(asfd)];
Убедитесь, что у вас нет метода -asdf, реализованного в этом классе haha
Или индекс за пределами исключения:
NSArray * array = [NSArray array];
[array objectAtIndex:5];
И, конечно же,
kill( getpid(), SIGABRT );
Как насчет хорошего старого:)
- (void)stackOverflow
{
[self stackOverflow];
}
Отправить сообщение освобожденному объекту
exit(0);
(должен... ввести... 30 символов)
Я думаю, что в Swift вы можете легко вызвать фатальную ошибку:
func foo() {
fatalError("crash!")
}
На самом деле даже предполагается использовать эту функцию в случае, если что-то пойдет не так, чтобы сделать сбой приложения.
Чтобы избежать оператора if в специальном случае, вы также можете использовать precondition. Он похож на assert, таким образом, намерение (если требуется) довольно ясно и не удаляется в финальной версии как assert. Он используется как precondition(myBoolean, "This is a helpful error message for debugging.").
Вы также можете создать исключение:
[NSException raise:NSInternalInconsistencyException
format:@"I want to test app crashes!."];
Добавьте распознаватель жестов в представление, которое распознает 10-кратный отвод (5 пальцев для iPhone, так как 10 могут немного переполняться). GR имеет прикрепленный к нему метод, который выполняет любой из ранее упомянутых верных способов заставить ваше приложение сбой. Большинство пользователей не будут класть 10 пальцев на ваше приложение, поэтому вы можете быть уверены в том, что обычный пользователь случайно вызвал сбой.
Однако вы должны использовать что-то вроде Testflight или просто развертывать его на личных устройствах и тестировать в дикой природе, прежде чем отправлять его Apple. После вынужденного сбоя ваше приложение может отклонить Apple.
может попробовать что-то вроде
NSArray* crashingArray = [NSArray arrayWithCapacity:1];
[crashingArray release];
должен произойти сбой на EXC_BAD_ACCESS (возможно, потребуется отпустить его второй раз, но нормальн он должен сработать как это уже)
Пойду с: int raise(int sig);
Чтобы получить дополнительную информацию >man raise
Я бы просто убил процесс нормально:
kill(getpid(), SIGKILL);
Поэтому, если вы устанавливаете обработчик с сигналом, вы также можете справиться с сбоем, заканчивая записью открытых файлов и этих вещей.
Я использую
[self doesNotRecognizeSelector:_cmd];
При работе с RubyMotion я использую это:
n=Pointer.new ('c', 1)
n[1000] ='h'
Попробуйте следующее:
- (IBAction)Button:(id)sender
{
NSArray *array = [NSArray new];
NSLog(@"%@",[array objectAtIndex:8]);
}
неверный оператор NSLog сделает это
NSLog(@"%@",1);