TypeScriptの異常系表現のいい感じの落とし所 | DevelopersIO
みなさんTypeScriptでサーバアプリケーション（Node.js）のロジックを書く時に、異常系の表現をどのようにされていますでしょうか？ここでいう異常系とは、仕様上想定される異常のことです。準正常系と言ったりもするかと思います。 私はJavaScriptの延長でTypeScriptをはじめたので、最初は null や undefined を返したり throw を用いるやり方をしていましたが、次第にTypeScriptが持つ型を生かし、できるだけ型安全に異常系を表現したいと考えるようになりました。そして試行錯誤した結果、いい感じの落とし所に落ち着いたので、その内容についてお伝えしたいと思います。 また記事の後半では、異常系の型を実装する中でハマった点についてもお伝えしたいと思います。 TypeScriptの異常系表現について 1. nullやundefinedを返す 冒頭でも述べたよう
エラーメッセージの読み方と対処, 検索や質問の原則 - Qiita
プログラミングをしている限り, エラーメッセージに遭遇するのは避けられないことだ. そこで, あなたは周りのできる人に「エラーが出ました」と言って "答え" を聞こうとするだろう. でも, もし聞ける人が誰もいなかったら? もし, 周りの誰にもわからないようなエラーにぶつかってしまったら? あなたが一人前のプログラマになるためには, 自分でエラーメッセージを読んで, 解決できるようにならなければならない. どういうエラーメッセージが出たときは何が原因で, どのように対処すれば解決するのか. その知識・経験の積み重ねこそがあなたを一人前のプログラマにするのだ. これは安直に "答え" だけを追い求めていてはいつまで経っても身に付かない. エラーメッセージの大原則 まず最初に頭に入れておくべきなのは, エラーメッセージは意味不明な暗号ではない ということだ. その実, エラーメッセージはかなり
良いエラーメッセージの書き方 - Qiita
エラーには大抵「エラーメッセージ」が付いています。 自分は過去に、エラーメッセージの内容を雑にしてしまい後悔することがよくありました。 その経験から、良いエラーメッセージの書き方を考えました。 エラーメッセージを2つに分類する まず、エラーメッセージといっても次の2つのパターンで大きく異なってきます。 (1) ユーザーが見るエラーメッセージ (2) 開発者が見るエラーメッセージ (1) ユーザーが見るエラーメッセージ 内部実装のことは書かないようにする
Swiftのエラー4分類が素晴らしすぎるのでみんなに知ってほしい - Qiita
これは Swift Tweets の発表をまとめたものです（次回開催はこちら）。イベントのスポンサーとして Qiita に許可をいただいた上で投稿しています。 ありがとうございました！Q&Aは他の人の発表中でも構わないのでリプを飛ばして下さい。 続いては僕 @koher の発表で、タイトルは "Swiftのエラー4分類が素晴らしすぎるのでみんなに知ってほしい" です。 #swtws — koher (@koher) 2017年1月14日 第 1 部: Swift の 4 種類のエラーについて あまり知られてませんが、エラー処理について、 Swift 2.0 設計時に Core Team がまとめた "Error Handling Rationale and Proposal" というドキュメントがあります。このドキュメントは、僕が去年 try! Swift で発表した際にも参考文献にしまし
Railsアプリケーションにおけるエラー処理（例外処理）の考え方 - Qiita
はじめに Railsアプリケーションを本格的に作り込んでいくと、「エラー」とは無縁ではいられません。 しょうもないバグでエラーが発生することもありますし、ほとんど不可抗力ともいえるような大規模なネットワーク障害でエラーが発生することもあります。 エラーの種類がなんであれ、エラーが起きた場合は「原因を素早く特定し、速やかに復旧させること」と「あるエラーが引き金になって、さらに大きなエラーに引き起こさないようにすること」が重要です。 エラー処理を適切に実装していれば、原因の特定や復旧もすばやくできますし、さらに大きなエラーを引き起こす可能性も少ないです。 また、ソースコードも比較的シンプルに保てます。 逆にエラー処理が不適切だと原因の特定に時間がかかったり、異常なデータがどんどん増えてさらに大きなエラーを引き起こしたりします。 ソースコードにも無駄に複雑な処理フローや条件分岐がたくさん出てきて
Sublime Text3で構文エラーをチェック
こんにちは、つい最近メディア事業部脱退を表明したデザイナーの王です。 PhpStorm、Aptana、NetBeansなど、大抵のIDEは、コードを書きながら構文エラーをリアルタイムでチェックしてくれるとても便利な機能がついていますよね。 個人的にはPhpStormが一番使いやすかったですが、IDEだと、プロジェクト単位で管理しなければならないので、小回りが効くSublime Textも以前から愛用しています。特にSublime Textの「Multiple Selections」という機能が凄く便利で、一旦慣れてしまったら、この機能が使えないPhpStormで作業するとストレスが溜まってしまいます!! でも、はやりIDEのリアルタイムコード解析は使いたいなぁ〜〜 でも…でも… こんな葛藤に苦しんだ結果、とある偉大なプラグインが誕生しました!!その名も「SublimeLinter」です！
Activity <App Name> has leaked ServiceConnection <ServiceConnection Name>@438030a8 that was originally bound here
I'm working on my first Android app. I've got three activities in my app, and the user switches back and forth pretty frequently. I've also got a remote service, which handles a telnet connection. The apps need to bind to this service in order to send/receive telnet messages. Edit Thank you BDLS for your informative answer. I have re-written my code in light of your clarification on the difference
基本中の基本！PHPのプログラミングエラーの種類と内容 | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
大体こんな事が原因でエラーが出ます。 E_ERROR / FATAL ： 実行時の状態がそもそも問題 ①呼び出す関数名間違い ②外部モジュールがエラーの場合 ③スペルミス ④複雑な家庭環境 E_PARSE / Parse ： 構文エラー ①セミコロン忘れ、閉じ忘れ ②全角スペース混入 ③視力低下または乱視 E_WARNING / Warning ： 警告。問題は発生するが処理継続 ①実行処理の失敗 ②参照先が参照できなかった場合 ③型が違う ④精神不安定 E_NOTICE / Notice ： 通知。問題になりうるが処理継続 ①未定義変数の利用 ②関数の引数がおかしい ③興奮状態 エラーが起きることでこんな被害が予想されます。 ①FatalとParseに至っては動作しないので、頭および実行結果が真っ白になってしまう。 ②いろいろな情報が出力されたりするので、脆弱性になりうる。 ③表示(レイ
JavaScriptと非同期のエラー処理
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog Yahoo!デベロッパーネットワークの中野(@Hiraku)です。前回のコールバック地獄に関する記事では、複雑な入れ子になりやすい非同期処理でも、GeneratorやjQuery.Deferredを使うことで、同期的な見た目に変形できることを示しました。 ところで、非同期処理においてはもう一つ「 エラー処理に例外が使えない 」という問題があります。今回はエラー処理について考えてみたいと思います。 例外を使ったエラー処理 非同期処理の話の前に、一度「例外」についておさらいしておきましょう。JavaScriptに限らず、エラーと言えばよく例外を使って記述されます。 「Web APIから500が返ってきた」とか「入力された値が期待する型
Androidアプリ開発で例外の発生した場所を特定する | DevelopersIO
以前、「iOSアプリ開発で例外の発生した場所を特定する」というブログを書きましたが、 Androidでも同じような機能があるようです。(むしろ、Javaですが。。。) Thread クラスの setDefaultUncaughtExceptionHandler メソッドというものを使いますが、 ここでオリジナルのクラスをセットすることにより、キャッチしてない例外発生によってアプリが強制終了したときの 「問題が発生したため、xxx(アプリ名)を終了します。」という、みなさんおなじみ？ のダイアログが表示される前に、任意の処理を差し込むことができます。 今回はそれを利用して、例外発生時のスタックトレースを SharedPreferences に保存して、メール送信するサンプルを作ってみます。 開発時などは、アプリをデバッグ起動していればEclipseのLogCatで例外発生時のスタックトレース
IS01 でオレオレMenuItem - gae+eyoの日記
MenuInflater に inflate させたオレオレMenuが IS01 に限ってクラッシュするようで...。 E/AndroidRuntime( 5690): Uncaught handler: thread main exiting due to uncaught exception E/AndroidRuntime( 5690): java.lang.AbstractMethodError: abstract method not implemented E/AndroidRuntime( 5690): at jp.syoboi.a2chMate.adapter.MenuAdapter$DialogMenuItem.setShortcutLabel(MenuAdapter.java) E/AndroidRuntime( 5690): at android.view.MenuI
iOSアプリ開発で例外の発生した場所を特定する その２ | DevelopersIO
前回は、例外の発生した場所を特定する方法として、「NSSetUncaughtExceptionHandler」を使った方法を紹介しました。 今回は、Xcodeの機能の「Exception Breakpoint」を使用して、例外の発生した場所を特定してみます。 （前回のブログで頂いたコメントを参考にしました。ありがとうございました。） 環境は、Xcode 4.5 を使用します。 例外を発生させる処理は前回と同じなので省略します。 以下、手順です。 ① Breakpointアイコンのボタンをクリックして、「Breakpoint Navigator」を開きます。（ショートカットは、「⌘」+「6」） ② 「+」ボタンをクリックします。 ③ 「Add Exception Breakpoint...」をクリックします。 ④ 「Done」ボタンをクリックします。 設定はこれで終わりです。 では、実行して
iOSアプリ開発で例外の発生した場所を特定する | DevelopersIO
iOSアプリを開発していて、例外が発生してアプリがクラッシュしてしまうことがしばしばあります。 Xcodeでは、クラッシュ時に得られる情報が少ないので、原因究明に時間がかかってしまいます。 そんなときは、「NSSetUncaughtExceptionHandler」を使用すると便利です。 まず、試しに、よくある例外をわざと発生させてみます。 - (void)viewDidLoad { [super viewDidLoad]; // ここで、わざと例外を発生させてみます。 [[NSArray array] objectAtIndex:0]; } 実行すると以下のようになります。 「UIApplicationMain」で止まってしまって、状況がよくわかりません。 「NSRangeException」が発生したことくらいはわかりますが、もう少し情報が欲しいところです。 そこで、「NSSetUnc
Java の語彙で Maybe を説明してみる - ぐるぐる～
java-jaで例外処理の話をしてきました - 西尾泰和のはてなダイアリー を読んで。 Maybe は値があるかないかを型で表すことができます！そう、直和型なんです！とか言われてもイミフだと思うのです(リンク先のエントリがそう説明してるわけではないですが)。 Java の語彙で Maybe の説明をできたら嬉しい人もいるんじゃないかなぁ、とかなんとか。 ただし、書いてたら結構長くなりました。時間がある人はどうぞ。 Maybe？ null より安全に「値がないこと」が扱えるものだよ スタート地点としてはこれでいいでしょう。 以降で、「なんで安全なの？」という全うな疑問に答えてみたいと思います。 問題点 int で説明すると煙に巻いてしまうような気がしたので、User クラスを見てみます。 import java.util.*; class User { final String name;
node.js におけるエラー処理のコーディングパターン (もしくは非同期 JavaScript における例外処理) - kazuhoのメモ置き場
node.js を代表とする JavaScript を用いた非同期プログラミング環境においては、コーディングパターンのベストプラクティスが共有されておらず、結果として品質の低いコードが多くなるという問題があるように思います。そこで、特にエラー処理をどう書くべきか、既存のライブラリを使う方法を紹介してみることにしました。 いきなりですが、ファイルの文字数を返す関数を作ることを考えてみます。Java だと以下のような感じになるでしょうか。countChars メソッドに注目すると、エラーを例外として扱っていて、モジュラーかつ簡潔になっていることがわかります。 class FileCounter { static long countChars(String filename) throws IOException { FileInputStream is = new FileInputStre
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rustエラーハンドリング・チートシート - Qiita
Swiftのエラー4分類 - 見やすくしてみました (あえてTwitter埋め込みという形式を選んでいるのであればスルーして下さい) - Qiita
Googleがプログラマのビルドエラーを研究
例外設計における大罪 - 契約