開発を始めて少し経つと様々なエラーに悩まされるようになることと思います。
そんな時に必要となるのは、どんなエラーが起きているのかを把握して、それに対処していくスキルです。
今回は、Xcodeでの開発におけるエラーを把握する方法(デバッグ方法)についてまとめていきます。
#1 基本的デバッグ方法
##超基礎
コンソールに表示されるエラー文を読もう
メッセージの意味が分からなければまずはググりましょう。
シンタックスエラーに対処しよう
コードの横に出てるエラー文を読んでググろうね
上記例では「Use of unresolved identifire 'newData'」と表示されています。
意味が分からなければググる習慣を付けましょう。
ちなみにこれは、「そんな言葉定義されてないぞ！」って怒られてます。
どんな場面でエラーが発生したのか、発生タイミングからエラー箇所を推定する
特に画面遷移時、イベント発生時に注意する。なんの操作をしてエラーが起きて落ちたのかで大体予想はつく。
プログラム実行前に、赤いマークがついているようなエラーをシンタックスエラー、プログラム実行中に何らかの操作をして落ちるエラーのことをランタイムエラーといいます。
ランタイムエラーの場合は特に、どういった操作をした時に落ちるのか、再現性はあるのかなどをしっかり見れば、大体のエラー発生箇所が予測できます。
##基礎
###1 printデバッグ
print()を活用してコンソールに変数の値を表示しよう
メソッドが呼ばれているかどうかをprint()を使って確認しよう
| print() | コンソール画面 |
|---|---|
 |
 |
###2 ブレークポイントの活用(ただのエラーじゃないよ)
変数の値チェック、実行手順の確認とかができます。
左端の行数を表示しているところをクリックすると青いマークがつきます。これはブレークポイントと言って、その行にプログラムが到達すると強制的にプログラムをストップして、プログラムの実行順や変数の中身を確認することができます。
左下のwindowで変数の値をチェックできます。
###3 コンソールの活用(poコマンド)
ブレークポイントなどでプログラムを止めた場合、左下コンソールwindowに(lldb)という文字が表示されていると思います。
この時、po(print object)コマンドを使って変数の値チェックなどを行うことができます。(lldb)はブレークポイントで止めたとき以外にもnilエラーなどのランタイムエラー時に表示されます。poコマンドはブレークポイントを設定していなくても変数の値チェックができるので便利です。
po monsterImageView.image
またpoコマンド内では、isProxyやdynamicTypeなどのメソッドも自由に使用できます。
po monsterImageView.image?.isProxy()
po monsterImageView.image.dynamicType
| コンソールウィンドウ |
|---|
 |
###4 View Hierarchy
UI関連のエラー、作ったはずの部品が表示されてないとか、思ったように配置できてないってときに使います。
見た目かっこいい
プログラム実行中にDebug WindowのView Dubug Hierarchyボタンを押す(右端のやつ)
現在表示されているアプリのViewを階層ごとに分類・解析できる
| ボタン(右端のやつ) | View Hierarchy |
|---|---|
 |
 |
#2 初心者が陥りやすいエラー集
シンタックスエラー編
文法エラーです。
Swiftの書き方が間違ってます。
ちゃんとSwiftを勉強しましょう。( Swiftはバージョンの更新が早く、文法もちょこちょこ変わっていたりするので写経をするなどしてSwiftの開発を勉強するときは要注意です。)
if文の書き方
プログラミングを勉強し始めたころは、if文の書き方もあやふやで、エディター(Xcode)に怒られることも多いと思うのでよく練習しましょう。
if a == 1 {
//処理
} else if b == 1 {
//処理
} else {
//処理
}
オプショナル：付け足すのは!か?か、それが問題だ
SwiftにはOptionalというnil管理をするためのとても良い機能がついています。
Optionalについては以下の記事がよくまとめられています。
[Swift] Optional 型についてのまとめ Ver2
@IBOutlet var label: UILabel //エラーになる
@IBOutlet var label: UILabel! //UILabelの後ろに!が必要
@IBOutletで宣言するUIコンポーネントなどは!を付けないとXcodeに怒られます。
しかし、!型(Implicitly unwrapped optional 型)はアンラップする際にnilが入っているとランタイムエラーを起こすので要注意人物です。
ランタイムエラー編
原因のほとんどが、正しい画面遷移先が指定されていない、UI Componentがnilになっている、nilエラー(OptionalのForced Unwrappingなど)によるものです。
関連付けエラー
関連付けエラーの際にAppDelegateに対してエラーマークがつくことが多いです。
また、画面遷移時に落ちる場合は遷移先のUIコンポーネント(画面の部品)がnilになっている可能性があります。
遷移先のUIImageViewがnilになっていないかどうかなどを調べましょう。
| ImageViewでnilエラーが起きてる |
|---|
 |
画像及び音声のリンクエラー
上記パターンと同様にnilエラーが起きていることが多いです。
画像や音声ファイルが、
- きちんとXcodeプロジェクトに紐付いていない
-
ディレクトリがネスト化していて、相対リンクではXcodeが認識してくれない
などが原因として考えられます。
こうしたミスを防ぐために画像ファイルは一元的に、Assets.xcassetsで管理するのをお勧めします。
| Assets.xcassets |
|---|
 |
|
ブレークポイントを知らないパターン
上記ブレークポイントを知らない人が、たまにこれは何のエラーなのかと頭を悩ませている姿を見ます。ブレークポイントをしっかり使いこなしてデバッグマスターになりましょう。知らない人は調べましょう。
is initial View
シミュレータを立ち上げた瞬間に画面が真っ黒になっている場合があります。
| シミュレータ | Storyboard |
|---|---|
 |
 |
|
これはStoryBoard上でis initial viewを設定していないことが原因です。
StoryBoard上で起動後最初に表示するViewControllerに対してIs Initial View Controllerにチェックをいれましょう。