TypeScript/JavaScriptの言語思想的にはtry/catchを使ってerror handlingをするのが普通
TypeScriptのError Handling - mrsekut-p
TypeScript/JavaScriptの言語思想的にはtry/catchを使ってerror handlingをするのが普通
Web VitalsとJavaScriptエラーの可視化 - フロントエンドにおけるObservabilityとは / visualize-web-vitals-and-javascript-error
Node学園 35時限目 オンライントライアルでの発表資料です。 Webアプリ・サイトの開発におけるObservabilityは、ユーザー体験(UX)の低下がいつどこで発生するかを検出し、開発者が改善にかかる時間を短縮するのに役立つ原因を把握することです。 構築をするには下記の3つのステップに区切ることができます。 ログを集める ログの詳細を可視化する ログの詳細から、改善に必要な意味合いだしを行う 最後の意味合だしを行うステップでは、情報を下記の3つのレベルに分類します。 エラー：空白ページの原因 警告：50ミリ秒を超えるハングアウト その他：デバッグなどの情報 この資料では、上記のステップを元に、AmplifyとQuickSightを活用したフロントエンドにおけるObservability向上の基盤を実装する方法を紹介しています。Observabilityの獲得により、フロントエンド開
Web VitalsとJavaScript Errorの可視化
こんにちは、@watilde です。Amplifyの開発者体験体験の向上をすべく、ツイートのウォッチやGitHubでの反応などしています。もう去年のことですが、最近はcliの改善としてcreate-react-appのようにinitの実行時にREADMEの生成を行うPRなど作ったりしてます。参考: aws-amplify/amplify-cli#5808 この記事は英語で書いた Improve UX by observability in front-end with Amplify and QuickSight を自分で日本語に意訳してみたものです。Node学園 35時限目 オンライントライアル でも同様の内容を発表予定です。 JavaScriptのエラー例 JavaScriptは100%動いているのか 私達の作るWebアプリ・Webサイトが様々なデバイスで100％動作しているかは、実態
Promise のキャンセルについて - Qiita
[ English version ] JavaScript と Node.js についてのこの徹底した投稿では、Promises のキャンセルの歴史、なぜNode.jsに関係があるのか、そして async/await APIで使おうとしたときに注意すべきことについて学ぶことができます。 この投稿は、JavaScript の Promise API をよく理解していて、 Node.js の経験がある方のためのものです。 歴史 2014 年に Promise API がブラウザに導入されて以来、人々は Promise で他に何ができるかを調べていました。ブラウザに最初に登場した関連APIは、HTTP リクエストのための fetch() でした。 HTTP リクエストの問題は、サーバーのリソースを消費することであり、サーバーに送信されるリクエストの数が多い場合はお金がかかります。このため、特に
Node.js v15ではunhandled rejectionでプロセスがエラー終了する
今月20日にInitial Releaseが予定されているNode.js v15ですが、ここでのunhandled rejectionの挙動変更について解説します。 unhandled rejectionとは async関数内でthrowされたエラーや、rejectされたPromiseが、.catch()などでハンドリングされずにrejectされたままになっている状態を、unhandled rejction（またはunhandled promise rejction）と呼びます。Node.js v14では、unhandled rejectionが発生すると次のような警告が出力されます。 $ node -e "Promise.reject()" (node:22145) UnhandledPromiseRejectionWarning: undefined (Use `node --trac
Promiseをthrowするのはなぜ天才的デザインなのか - Qiita
ReactのConcurrent Modeが最初に発表されたのはもう1年近くも前のことです（記事執筆時点1）。Concurrent Modeはたいへん奥深い機能で正式版がたいへん待ち遠しいですが、Concurrent Modeの代名詞として多くのReactユーザーに知られているのはPromiseをthrowするというAPIデザインです。Concurrent Modeでは、コンポーネントがレンダリング時にPromiseをthrowすることで、レンダリングをサスペンドした（Promiseが解決されるまでレンダリングできない）ことを表します。 Concurrent Modeに関しては筆者の既存記事Concurrent Mode時代のReact設計論 (1) Concurrent Modeにおける非同期処理などをご参照いただきたいのですが、ここではPromiseをthrowするということ自体に焦点
Hegel,新しいJavaScript型チェッカ
原文(投稿日：2020/05/19)へのリンク 新ライブラリのHegelは、JavaScriptで高度な静的型チェックを実現しようという試みだ。強い型推測と完全な型システムを提供するという。現在はまだアルファ版だが、専用のオンライン・プレイグラウンドで動作を確かめることができる。 Hegelは型アノテーションを備えたJavaScript用の型チェッカである。TypeScriptの場合のように、新たなプログラム言語構造を学ぶ必要はないが、アノテーション記法についての学習は必要だ。Hegelは強い、完全な型システム(Sound File System)を使うことで、実行時の型エラーを防止する。 const numbers: Array<number> = []; // HegelError: Type "Array<number>" is incompatible with type "Arr
MarkdownやAsciidoc中に書いたJavaScriptのサンプルコードをdoctestするツールを作った
技術書、ブログ、READMEを書いてていて、文章中に出てくるコードブロックのコードをテストしたいことがあると思います。 そのサンプルコードが本当に動いてるのか不安になることがあるからです。 power-doctestは、そのコードブロック中のコードにコメントを入れるだけでテスト可能にするツール群です。 power-doctestの例 具体的な例から見ていきます。 次の例では、Markdownで説明とJavaScriptのコードブロックを書いています。 デフォルト引数を使って書くことで、このような挙動は起きなくなるため安全です。 デフォルト引数では、引数が渡されなかった場合のみデフォルト値が入ります。 ```js function addPrefix(text, prefix = "デフォルト:") { return prefix + text; } // falsyな値を渡してもデフォルト
JavaScript で throw "" ではなく throw new Error() を使ったほうがよい(些細な)理由 - latest log
JavaScript で人為的に例外を発生させるには、大きく分けると以下の2種類があります。 throw new しない書き方 throw "ソフトウェアでエラーが発生しました。サポート担当者に連絡し、この問題を報告してください。"; o_o は String 扱いで、o_o.stack も undefined になっています。 throw new する書き方 throw new Error("一般的なエラーだよ"); throw new TypeError("型がちがうよ"); throw new SyntaxError("文法おかしいよ"); throw new URIError("URIちがうよ"); 他にも、RangeError, ReferenceError, MediaError, FileError, EvalError などがあります。 throw new した場合は、o_
スタートアップで働くプログラマが、非プログラマの皆さんにお願いしたいこと - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 自分の基本はプログラマとして、サーバーサイドのサービスをゴリゴリ書くのが仕事だ。しかし、仕事をするとなると、いろいろな人が絡んでくる。もちろんマーケティング担当や戦略担当の人もいる。そして、僕はそういう人たちが実際にやっていることはわからないけれど、それはたぶんそういう人たちが「プログラマってどういう仕事なのか？」ということがわからないのは一緒なのだろうと思う。もちろん、お互いに相手の仕事を理解して、それに合わせてどういう風なことを共有して作ってもらうか、というのを話し合う機会は重要だ。 たぶん、自分たちがどのように仕事をしていて、どのように情報を共有してもらえれば、仕事がスムーズにいくのか、ということを説明しないことには、たぶん「プログラマが理解されない」ということを嘆いても仕方ないと思う。なので、まず自分が「プログラマとしての自分」が考えていることを共有する必要があるなあとい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ユーザのブラウザで起きた JavaScript のエラーを収集する - Qiita