The Haskell Error Index — Haskell Error Index
Welcome This site describes the various messages that can be returned by Haskell-related tools, including both errors and warnings. For example GHC, the most-commonly-used Haskell implementation, started emiting a code with the format [GHC-12345] for its messages in version 9.6.1. These codes can be looked up below for further information. Other Haskell-related tools are welcome to add their own m
Error Messages in Haskell, and how to Improve them
Main.hs:3:11: error: • No instance for (Num a) arising from a use of ‘+’ Possible fix: add (Num a) to the context of the type signature for: foo :: forall a. a -> a -> a • In the expression: a + b In an equation for ‘foo’: foo a b = a + b | 3 | foo a b = a + b | ^^^^^ On a pure technical level, this is correct. The usage of (+), as a function with type signature (Num a) => a -> a -> a, causes a co
Exceptions Best Practices in Haskell - FP Complete
The content below is still correct, but has been absorbed into the more comprehensive safe exception handling tutorial document instead. I recommend reading that, which provides more information and more up-to-date library references. Over the years, I’ve written a number of different documents, tutorials, comments, and libraries on how to do proper exception handling in Haskell. Most of this has
VoiceUI / VoiceUX デザインことはじめ - Qiita
はじめに 長々と書いていますが、VUIのキモはたった一つと言っても過言じゃありません。 エラーハンドリングです。 エラーの対応ができていないと全てが台無しです。 筆記とは違い、老若何女問わず毎日会話していますから、会話だけは人間誰でもプロなんです。 話の通じない人と話すのは誰もが嫌がります。 普通に指示して、「わかりませんでした」と、これほど失礼なことはありません。 せめて、「分かんなかったけれど、こう言ってもらえればわかる」を示して挽回するのです。 エラーハンドリングをして、次に何を言って欲しいかきちんと言えば大半のタスクが完了できます。 あ。二つだった。 VUIとは Voice User Interface、声で操作するインターフェイスです。 今ご覧になっているGraphic UIや、エンジニアの利用するCommand UI、チャットボットのConversational UIとは異なり
良いエラーメッセージの書き方 - Qiita
エラーには大抵「エラーメッセージ」が付いています。 自分は過去に、エラーメッセージの内容を雑にしてしまい後悔することがよくありました。 その経験から、良いエラーメッセージの書き方を考えました。 エラーメッセージを2つに分類する まず、エラーメッセージといっても次の2つのパターンで大きく異なってきます。 (1) ユーザーが見るエラーメッセージ (2) 開発者が見るエラーメッセージ (1) ユーザーが見るエラーメッセージ 内部実装のことは書かないようにする
例外、エラー、異常、そして - Qiita
「例外」「エラー」「異常」あたりの言葉が、言語仕様や設計の中で人によって微妙にずれた使い方されてるから、 「Expected だが Accept されないケース」を表す別の言葉が欲しい。 — Jxck (@Jxck_) 2016年8月31日 @Jxck_ 本来こう分類されて、 1. Expected/Accepted 2. Expected/UnAccepted 3. UnExpected 2, 3 をどう呼ぶかあたりで、例外, エラー, 異常などの言葉が入り乱れてて、それが広義の例外処理が誤解される原因だと思ってる — Jxck (@Jxck_) 2016年8月31日 Expected and Accepted Expected but Unaccepted Unexpected
エラーメッセージは 2W1H がいいんじゃないか
良くあるダメなエラーメッセージ エラーが起きたときは、以下のようにエラーメッセージをどこかしらに出力すると思います。 $c->log->error('something wrong!'); ただ、このエラーメッセージって、実際に発生したときには意味がわからないことが多いのです。 $c->log->error('error!'); 本気でこういう「error!」とだけ吐くメッセージだと、エラーが起きたことしか伝わってきません。程度の差はあれ意味のわからないエラーメッセージはこの世にあふれているかと思います。 機械的なエラー情報 そういうわけで、たいていは Exception クラスや Logger クラスで多くの補助が受けられるようになっていると思います。 発生時刻 発生場所 stack trace 変数の状態 ただ、このような機械的な情報だけだと、結局、運用上は対応が難しい場面ってのが多か
HTTP/2 のエラーハンドリングと Request Reliability Mechanism - Qiita
この記事で伝えたいこと HTTP/2 では、「stream」と「frame」と呼ばれる構造を導入することで、複数のリクエストを 1 つの TCP セッションで送受信できるようになりました。この構造の変化に伴い、HTTP/1.1 以前には存在しなかったエラーがあります。 そこで、この記事では HTTP/2 で新たに考慮すべきエラーを洗い出し、どう対処すべきなのかを整理します。 付録として、HTTP/2 のエラーを活用することで実現した「Request Reliability Mechanism」を説明します。 1. 変わらない部分：ステータスコード HTTP/1.1 で利用していた「404 Not Found」や「500 Internal Server Error」などのステータスコードは、HTTP/2 にそのまま引き継がれます。したがって、HTTP アプリケーションで発生するエラーは、HT
WebAPIでエラーをどう表現すべき？15のサービスを調査してみた - Qiita
2017-01-05 追記 2016年3月にエラーの標準形式RFC7807「Problem Details for HTTP APIs」が提案され、今日現在proposed standard(標準化への提唱)となっています。こちらも是非ご覧ください。 RFC 7807 - Problem Details for HTTP APIs HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様 最近はREST APIを提供しているサービスが増えてきていますね！また公開されるAPIだけでなく、Microservicesなアーキテクチャを採用して、バックエンドがWeb APIで通信するケースも増えてきているように思います。 APIを使うときはあまり気にしたこともなかったですが、いざAPIを設計してみるとどんなインターフェイスがいいのか、どんな形式がいいのかといった疑問が次々と出てきます。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - bollu/hask-error-messages-catalog: A catalog of broken Haskell programs to improve error messages