2016-03-18 5 views
-4

私はこのロジックは、何かが内側にうまくいかない場合は、アプリケーションをクラッシュ避けたい、このようにバックグラウンドスレッドでアプリケーションをクラッシュさせるためにランタイムエラーを禁止する方法はありますか?

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0), {() -> Void in 
     ... 
}) 

をする方法を実行していますよ。そうする方法はありますか?

があればバグを修正答えないでください、私は見つかっていない任意のpotencialバグについて話しています。これは、サーバからのデータを処理するタイマーで動作します。クラッシュした場合、起動時にクラッシュするため、アプリケーションを使用できなくなります。

のAppは、最悪の場合には、このデータ処理なしでは生きていけますが、アプリがすべてで使用することはできませんので、起動時にアプリケーションをクラッシュすることははるかに悪化していることができます。

私は予期しない例外のキャッチを持っていませんスウィフトを知っているが、おそらく、物事がうまくいかない場合@nhgrifが言っているエコー

+3

いいえ、いいえ、いいえ、いいえ、いいえ、いいえ、いいえ。これは良いアイデアだと思った他の人が作ったレガシーアプリを扱わなければならなかった人物と言えば、これをどうしてもいけません。ただしないでください。これをまったくやってはいけません。理由はありません。バグを修正するか、クラッシュする。しかし、あなたがしたいことは、まったく受け入れられないバグを隠すことです。言うまでもなく...あなたが求めていることをする唯一の方法は、スレッド全体を孤立させること(そしてそのスレッドに割り当てられたメモリをすべて漏らすこと)を意味します。 ***これをやってはいけない!! *** – nhgrif

+0

このアプリは4日間のイベント用です。予期せぬバグが発生してクラッシュした場合、おそらく時間内に修正する機会はありません。絶対的な真実を持っている?私は明らかに私が見つけていないバグについて話しています... – StackOverflower

+6

あなたはクラッシュせずに失敗する方法を見つける必要があるので、すべてのあなたの力を解くコードを取り除くことから始めます。 – nhgrif

答えて

1

アプリがクラッシュするバックグラウンドスレッドを回避するための方法があるが、これは本当に悪いです私がバグを修正する能力を持っていない他の誰かからのコード、すなわち、制御されていないコードの大部分のケースである場合にのみ私が検討するものです。私は考えることができる

つのオプション:

  1. プロセスの障害が子プロセスの終了になりますが、親プロセスが終了しない場所、別のプロセスで処理を実行します。

  2. 、どちらか、あなたは* nixのプラットフォーム上で実行していると仮定すると、iOS版、MacOSの、Linuxの、など、あなたがなどC、C++、これらの例外をキャッチするために使用するのと同じsignalsigaction呼び出しは、ご利用いただけますあなたは例外的な状況を処理し、おそらくより正常に終了するためにそれを使用できるかもしれません。

ここでも、これらの両方が本当に実行時の失敗は致命的であり、修正する必要があり、周りに働いていないということである、スウィフトの基本原則の一つの多くに違反して、恐ろしいアイデアのように感じます。

+0

私はこの回答が気に入っていますが、どちらのオプションもiOSで利用できません(2番目の回答が分からない限り)。私はこのユーザーが求めていることをする方法を知っています...しかし、私はそれを行う良い理由がないので、その知識を共有することを拒否する... – nhgrif

+0

スウィフトの哲学は:あなたが間違いを犯した場合、完了ですか?バグがプロダクションビルドになってアプリがクラッシュした場合、あなたは泣くしかありませんか?私が試みなしでキャッチを入れることができれば、クラッシュスティックにログを送り、バグを細かく処理し、アプリをクラッシュさせずに行動することができます – StackOverflower

+0

いいえ、スウィフト哲学は...コンパイル時に多くのクラッシュを防ぎます言語の性質上、生産前にバグを検出する優れた自動テストツールが数多くあり、Crashlytics/Fabric.IOのような偉大な図書館があります。 – nhgrif

関連する問題