ggrksと追い返されないための3ステップ エラーメッセージ編

シェアする

ヨメレバCSS

 「聞くは一時の恥、聞かぬは一生の恥」といいまして、質問することはしないことに比べて大変よいことです。 そして世の中にはどれだけ聞いても恥にならないチート的存在が存在しております。そうGoogle先生です。  

 さてエラーメッセージ。だいたい英語で嫌になりますが、実のところ調べやすい部類だったりします。なぜならだいたい誰かが踏んでて、その誰かはエラーメッセージをまるっとコピペして質問してくれていたりするから。 英語も英文というより単語の羅列みたいな程度の理解で、なんとなく何が拙いか分かればOK程度であるので、敬遠せず挑んでいきましょう。  

1.エラーメッセージを読んだか?

→Yes 2.へ  

→No 読め。

 いいからまず読め。英語だと思うな。単語の羅列だと思うんだ。 英語だから読めないといってる間にまずその単語をぐぐれ。Google翻訳にぶちこめ。 enable…permission…variable…なんとなくよく見る単語が並んでいるはずだ… エラーメッセージの文法なんてあってなきようなもの。「変数がやばいんだな」「このファイルがやばいんだな」程度でいいから雰囲気つかんで欲しい。  

読んだら2.へ。  

2.エラーメッセージはミドルウェアのもの?

→Yes エラーメッセージをコピペしてGoogle検索にたたき込め! そして3.へ  

→No 速攻聞きに行こう

 社内システムのメッセージなんかぐぐってでてくるわけないでしょ。聞くしかない…   ただ社内システムでも情報が公開されていれば別。また、出力しているのは社内システムだけど、SQLのエラー結果をそのままだったりしたらそれはミドルウェアのエラーとする。検索窓でも社内掲示板でもありそうなところにコピペしたエラーメッセージを放り込んで3.へ。  

要は、外部に情報が期待できるかどうかですね。  

切り分けらんなかったらとりあえずエラーメッセージを検索窓にぶちこんで3.へ。  

3.検索結果をヒントに解決できた?

→Yes おめでとう! もう教えることは何も無い…  

→No まだだ…まだあきらめてはならない… エラーメッセージの中に入っている、ファイル名や変数名など固有のものは取り除いて検索して3.へ。

 エラーコードがあれば、それだけで検索してみて3.へ。

 ミドルウェア名+呼んでいたAPI+関係ありそうなAPI+トラブルの事象などを思うがままに列挙して3.へ。

 エラーメッセージは短かったらそのままでもいいけど、長いものの場合は適当に抜粋して放り込んでみると引っかかってくることがあります。 あと、半角空白で区切るとor検索になるんですが「”」(ダブルコーテーション)で囲んでやるとそれをひとかたまりとして検索してくれるので、エラーメッセージの適当な長さの部分を”で囲んでやるとヒットしやすい。    

3.のループに万策尽きたら両手を天に挙げ「万策尽きた!」と叫んでから聞きにいってみましょう。 きっと無碍にはされないはず。たぶん。ケーキがあるとなお良し。 

 検索で調べるのはみつからないときはとことんみつからないくせに、調べる人が調べると意外とあっさり見つかって嫌になるんですが。 だいたい一目見て、「あっこいつ調べてねえな」という疑い持たれるレベルの事項というものはあります。なぜなら自分が過去に何度も遭遇してぐぐった経験あるやつだから。  

 大切なことは全部Google先生が教えてくれる…あとウィキペディア…あれはあかん…永遠に時間を飲み込む知の底なし沼や…(そのままリンクをたどり続けてしぬ     あと一応な、出てきたエラーメッセージに機密っぽいやばい情報とかあったらそのままググったらあかんで。

 ちゃんとそこは除いてやらんと。そういうことは滅多にないと思うけど。 ファイル名とか変数名とか、関連する何かしらのシステム情報が含まれている場合が多いからその扱いだけは一呼吸置いてから。 大抵は、その部分を除いても検索結果でますし。

 というかそういう環境によって可変する情報は、むしろ邪魔になる場合が多いかもしれない。  

スポンサーリンク
レクタングル (大)

シェアする

フォローする

スポンサーリンク
レクタングル (大)