![セキュリティ／プライバシー研究者による年齢確認に関する共同声明 » p2ptk[.]org](https://cdn-ak-scissors.b.st-hatena.com/image/square/92eda4328805db8b2e4b07bd2e3dd55a79cf12df/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fp2ptk.org%2Fwp-content%2Fuploads%2F2026%2F04%2Fgaelle-marcel-FLdK5N-YGf4-unsplash.jpg)
例外処理とどう使い分ける？Result型を使ったエラー設計 #burikaigi
例外処理は、単なるコード上の仕組みではなく “失敗とどう向き合うか” を決める設計上の意思決定です。 エラー対応が「起きた後の対処」だけに偏ると、再発と手戻りは減りません。 Result型は、失敗の可能性を型で表し、例外に頼らずエラーを設計する手法です。 これにより、エラーの種類や処理責任が明…
タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
例外処理は、単なるコード上の仕組みではなく “失敗とどう向き合うか” を決める設計上の意思決定です。 エラー対応が「起きた後の対処」だけに偏ると、再発と手戻りは減りません。 Result型は、失敗の可能性を型で表し、例外に頼らずエラーを設計する手法です。 これにより、エラーの種類や処理責任が明…
現実のアプリケーションで発生するすべてのエラー・例外をResult型に変換するのは非現実的 エラーハンドリングが不要なものはUnexpectedErrorとしてまとめてしまう という現実的な落とし所を提案する記事です。 TypeScriptにResult型を導入したくなる理由 TypeScriptのエラーハンドリングは、try…catch文を使うのが基本です。tryブロック内でthrowされた例外はcatchブロックで捕捉されます。 try…catchによるエラーハンドリングには、以下の問題があります。 例外がthrowされる可能性がある関数かどうかが型シグネチャに表れないため、呼び出し時にtry…catchが必要かどうかわからない exceptionVarの型がunknown（設定によってはany）のため、エラーの種類に応じたハンドリングができない try…catchを細かく切って個別に
こんにちは、よしこです。 この記事では、わたしの所属する株式会社ナレッジワークで最近コードベースに取り入れた「エラーハンドリング漏れ防止の仕組み」について紹介します。 背景 「通信を伴うアクションに失敗しても画面にエラーフィードバックが表示されない」という実装漏れをしてしまったことがあり、今後こういうことが起きないように仕組みで防止したいと思いました。 「忘れてしまった」という問題なので、テストで担保するのも難しいように思いました。実装するのを忘れてしまっているということは、テストを書くこともセットで忘れてしまっているはずだからです。 「気をつける」「チェックリストを作る」のような人間が注意する方向ではなく、「嫌でも気付く」「忘れていたらCIが通らない」のように、必要なハンドリングを強制する形にできないか？と思いました。 課題 実行時に通信エラーが起きる可能性があり、ユーザーフィードバック
副作用とロジックの分離。Railway Oriented Programming と Result 型で 「テストしやすい」バリデーションの設計 - カミナシ エンジニアブログ
こんにちは、カミナシでソフトウェアエンジニアをしているShimmyです。 カミナシでは現場のDXを支援するB2B SaaSプロダクトを開発しています。そのうちの1つである「カミナシ レポート」の「ひな形編集」機能では、ユーザーがフォームテンプレートを自由に作成できます。 ひな形の保存前には約20種類のバリデーションを実行します。ひな形名のチェック、回答項目の設定確認、設定キーの重複チェックなど多くのバリデーションがあり、今まではこれらが 1つの巨大な関数 でした。 今回は、関数型プログラミングのアプローチである 「Railway Oriented Programming」 と 「Result型」 を TypeScript で使って、数百行あるバリデーション処理を改善した話をご紹介します。 改善前のコード：何が問題だったのか 改善前のバリデーション処理を簡略化して書くと、次のようなコードです
2025年06月19日追記： 弊社のメンバーが、TypeScriptの新しいResult型ライブラリ「@praha/byethrow」を作りました！ NeverThrowを使用中の方、もしくは使用を検討している方は、ぜひ@praha/byethrowも試してみてください！ 紹介記事：TreeShakableなResultライブラリを作りました 会社でNeverThrowというライブラリを使っています。 とても便利なので、とても便利だよ〜という記事を書きます。 NeverThrowとは？ NeverThrowは、TypeScriptで「Result型」を実現できるライブラリです。 Result型とは？ Result型は、関数の中でエラーをthrowする代わりに、エラーを戻り値として返すようにすればいいじゃね？な仕組みのことをいいます。 もっと噛み砕いて説明します。 たとえば「50%の確率で足
Result 型 (類似するものとして Either Monad の方が有名かもしれません) を導入する場合、アプリケーション全体の設計を変えたり、全箇所を書き換える必要はありません。 neverthrow は部分的に使用でき影響範囲も閉じるので、局所的に使い始めることができます。 (Rust のような) Result 型 とは ざっくり言うと関数の処理の結果と成否を 1 つの型 Result<T, E> で表したものです。(T は期待する結果の型、 E はエラーを表現する型) 筆者は詳しくはないのですが、 Haskell 等にある Either<L, R> とは厳密には違うようです(Either は両方の値が使用可能であることを前提としている？) 参考: Rust ではなぜ、Either 型ではなく Result 型を採用しているのか neverthrow とは TypeScript で
はじめに Result型の定義とサンプルコード Result型を使わない場合 Result型を使う場合 なぜResult型を使うのか 関数シグネチャで、呼び出し元が処理すべきエラーを伝えることができる 呼び出し元にエラー処理を強制できる 復帰可能なエラーと復帰不可能なエラーを明確に区別できる エラー処理を簡潔に書ける なぜkotlin-resultを使うのか メソッドが豊富に用意されている エラーの型を自由に設定できる Result型を使ったエラーパターン 単純なエラーメッセージを返す 構造化したエラー情報を返す 複数のエラー情報を同時に返す 型による分岐が可能なエラーを返す kotlin-resultの基本メソッド get() / getError() unwrap() / unwrapError() onSuccess() / onFailure() map() / mapError(
moto on Twitter: "職務経歴書は「STARS」というフレームワークを使って書くのがおすすめよ。 ・Situation :どんな環境で ・Task :どんな任務を持ち ・Action :自分は何を実行して ・Result :結果どうだったのか ・Se… https://t.co/CezthQVxW6"
職務経歴書は「STARS」というフレームワークを使って書くのがおすすめよ。 ・Situation :どんな環境で ・Task :どんな任務を持ち ・Action :自分は何を実行して ・Result :結果どうだったのか ・Se… https://t.co/CezthQVxW6
GitHub - IBM/fp-go: Functional programming library for Go 1.24+, inspired by fp-ts. Uses generic type aliases for a clean, composable API. Provides Option, Either, Result, IO, IOResult, Reader, and ReaderIOResult monads, plus optics (Lens, Prism, Traversa
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Rust初心者の筆者「アドカレ完走！書いた文字数をカウントしてブログに乾燥した換装書くぞ！」 初筆「せっかくだし文字数カウントスクリプトもRustで書いてみるか。ディレクトリにあるファイル群を読み込んで各ファイルの文字数を表示しよう」 fn get_files(dir_name: &str) -> Vec<String> { let mut files = Vec::new(); let entries = std::fs::read_dir(dir_name).unwrap(); for entry in entries { let entry = entry.unwrap(); let path = entry.path(); if path.is_file() { files.push(path.to_string_lossy().into_owned()); } } files }
Ktor × Exposed × Koin × kotlin-resultを用いたDDDを意識したアプリケーションの実装 - Don't Repeat Yourself
ここ数年で『関数型ドメインモデリング』という書籍や、『Functional and Reactive Domain Modeling』といった書籍を読んだ経験から、今業務で取り組んでいるKotlinではどう表現できるのかに興味がありました。年末年始に少しまとまった時間が取れたので、実際に実装してみました。今回は、その過程でどのような知見を得られたかを、主には自分の理解のためにまとめておきたいと思います。 関数型ドメインモデリング ドメイン駆動設計とF#でソフトウェアの複雑さに立ち向かおう (アスキードワンゴ) 作者:Scott Wlaschin,猪股 健太郎ドワンゴAmazon github.com 先に書いておきますが、長いです。目次をご覧になって、興味のある場所をかいつまんでお読みください。 免責事項 お題 技術スタック 設計 全体的な設計 Kotlinの使用に関するもの データ型の定
Rust, Kotlin, Swiftなどのモダンな言語ではいわゆるResult型が標準で提供されていますがTypeScriptにはありません。 既にいくつものResult型のnpmパッケージが公開されているのですが、自分好みのものが見当たらなかったので自作しました。 設計上の工夫 TypeScriptでは型と同名の名前空間を両立して定義できます。 この仕様を使って型（export type Result）と名前空間（export namespace Result）の両方を定義し、ヘルパー関数などは全て名前空間の中に配置しました。 そのおかげでResultだけをimportすれば済みますし、関数名などを覚えていなくてもエディターの候補表示から全てのユーティリティを辿れるようになっています。 こういう設計にするとTree shakingが効かなくなってしまうのですが、Result型だけの小さ
fast-checkとneverthrowのPBT+Result型で 堅牢なビジネスロジックを実現する
2025/5/23 TS Kaigi 2025登壇資料
TypeScriptへRustのようなResult型の導入をお勧めする記事や言説が多いので導入してみましたがあまりよくなかったです。という共有になります。 Result型を導入しても try-catch からは逃れられない これに尽きます。 Result型を導入したあと、try-catch を末端に押しやってそこ以外はResult型のみの世界を実現しようと、おそらくみんな考える。でもそれは機能しない。 実際にやってみるとこんなコードが多発する。 副作用部分だけ閉じ込めれば綺麗になるか API呼び出しなどの副作用だけ閉じ込めればこんなコードは避けられると考えるかもしれないが現実は甘くない。 JavaScriptのさまざまな組み込み関数が例外を発生させるし、nullやundefinedへのアクセスも例外を発生させる。これらの多くはRustやGoで言うところのpanic扱いだから戦略を分けて、ユ
airreader.hatenablog.com の回答結果が出揃った。回答データはGA4に送っていたのでそれをLookerStudioなどを使ってまとめた。 回答にかかった時間 正答率 誤答関連 回答にかかった時間 今回、motemenアイコンが表示されてから回答が送信されるまでにかかった時間を計測していた。 送信された全ての回答で、motemenアイコンが表示されてから回答が送信されるまでにかかった時間の中央値は21秒だった。正答が送信された時間の中央値は57秒で、全回答時間の中央値や誤答時間の中央値の2倍の時間がかかっていた。やはりじっくり見ないと正答できないという傾向はあるだろう。 最速の正当時間は12秒で、このような成果を挙げられるのは、脊髄でmotemenを理解しているか、1/16 の確率に勝利した場合に限られるだろうと思う。 正答率 正答数は21で誤答数が139ということは、
GitHub - samber/mo: 🦄 Monads and popular FP abstractions, powered by Go 1.18+ Generics (Option, Result, Either...)
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Tree-shakable error handling with functional programming approach
この記事は NSSOL Advent Calendar 2022 の1日目の記事です はじめに 私が現在所属しているチームでは、フロントエンドもバックエンドも共にTypeScriptをで開発を進めており、具体的にはフロントエンドではReact、バックエンドではNestJSを使用しています。 TypeScriptで共通化させることで、TypeScriptが提供する型安全性を享受しながらも、バックエンドとフロントエンドで大きなコンテキストスイッチを発生させることなく開発を進めることができていると感じています。 ただ、実感としては、バックエンドではソフトウェアで解決したい対象となるドメインのモデルを class で表現したり、フロントエンドのReactでは小さい関数や hooks を集約させることでロジックを表現したりと、フロントエンドとバックエンドでのロジックの構築方法に差異を感じていました。
GitHub - arthurfiorette/proposal-try-operator: A proposal to bring ergonomic, inline error handling to JavaScript through a new try operator that always returns a Result.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
PHPではtry-catchによる例外処理が一般的ですが、「どこで例外を処理すべきか？」「本当にこの場面で例外を使うべきなのか？」と迷ったことはありませんか？ 過剰なエラーハンドリングや、catchしたけれど何もしていない“握りつぶし”が積み重なると、責任の所在が曖昧になり、コードの見通しや保守性にも…
kotlin-resultを半年使ってみて
はじめに ログラスの小林(@mako-makok)です。 この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint" の 4 週目 の記事です！ 1 年間連続達成まで 残り 49 週 となりました！ Kotlin でのエラーハンドリングの改善に向けて、kotlin-resultというライブラリを導入したのですが、使い始めて約半年経過しました。 今回は使ってみて実際にどうだったかを振り返ってみます。 What kotlin-result Rust のResultや、Scala の Either など、関数型の概念を取り入れた言語には例外ではなく、失敗する可能性のある処理は成功と失敗の型をシグネチャで表現できるようになっています。 kotlin-result は それらの表現を Kotlin でも利用できるようにしたライブラリです。 内部の実装を見てみるとそ
PerlでResult型を扱うResult::Simpleをリリースしました - Blog::kobaken
metacpan.org 簡単な利用例 Result型は関数の戻り値を成功または失敗として表して、安全なエラー処理をする旨味があり、F#、Rust、Goなど他の言語でも使われています。詳細は他に譲ります。 Perlでも同様にその旨味は享受できます。加えて、このモジュールの実装は、名前の通りシンプルです。関数の返り値をオブジェクトで包む実装を見ることがありますが*1、そういうことはしていません。($data,undef) または (undef, $error) のタプルで結果を表現しています。例えば、Ok関数の実装を見てください。以下の通り、単純です。 # When the function is successful, it should return this. sub Ok { if (CHECK_ENABLED) { croak "`Ok` must be called in lis
「Result型」を見てみよう type Result<T, E extends Error> = Success<T> | Failure<E>; class Success<T> { readonly value: T; constructor(value: T) { this.value = value; } isSuccess(): this is Success<T> { return true; } isFailure(): this is Failure<Error> { return false; } } class Failure<E extends Error> { readonly error: E; constructor(error: E) { this.error = error; } isSuccess(): this is Success<unknown>
Rust Option and Result
dealing with the Option and Result enum Posted on September 1, 2021 A thorough understanding of the Option enum and the Result enum are essential to understanding optional values and error handling in Rust. In this ariticle, I will work my way through both of them. Introduction To understand the Option and the Result, it is important to understand the following: the enum in Rust matching enum vari
result - hm2192’s diary
お好み焼き焼きました 」 まぁまぁでしょうか いつもと変わらずですね フライパンが熱いうちに ソース～マヨまで行ってしまいます 縁のソースが焦げていい香り このいい香りも味のうちですよね こういうスタイルで食べることが多いです たまに白飯も付けちゃう いつもは細切れ肉を使ってますが 今回はバラ肉で行きました 肉の旨味がちゃいますねぇ
はじめに JavaScriptでは、throwを使ってエラーを明示的に投げることで、処理を中断する「大域脱出」が可能です。しかし、TypeScriptではこのthrowによって発生するエラーの型を記述できないため、型安全性が損なわれてしまいます。 この問題を解決するために、関数の成功・失敗を明示的に扱えるResult型が有用です。 TypeScriptでResult型を利用する場合、neverthrowやeffect-ts、fp-tsなどのライブラリがよく挙げられます。 しかし、それぞれ一長一短があり、neverthrowは比較的シンプルで使いやすいものの、現在は活発なメンテナンスが行われておらず、複数のPRが長期間放置されています。 effect-tsやfp-tsは高機能ですが、Result以外の多くの概念も含んでいるため、「Resultだけ欲しい」ケースでは導入コストが高く、バンドルサ
検査例外にさよなら！KotlinのRailway Oriented Programming by kotlin-result
はじめに 惜しくも(?) Kotlin Fest 2024で採択とならなかったセッションの供養を行います。とはいえ、全ての内容を網羅することはせず、かいつまんで話したかった内容を書いていきます。 Railway Oriented Programmingとは？ Railway Oriented ProgrammingとはScott Wlaschin氏によって提唱された設計です。 詳細は全て無料でこちらから見れるのでぜひチェックしてみてください。 簡単にいうとRailway Oriented Programmingとは正常ケースと異常ケースの2つのレールを型で表現しながら設計をする手法です。 関数型プログラミングでは、RustのResultやScalaのEitherに代表される成功値かエラー値かのどちらか一方の値を持ったデータ構造を使ってエラーハンドリングを行います。以下はRustのResul
[レベル: 中級] About this result 機能が日本語でも利用できるようになりました。 日本語名は「この結果について」です。 次のプロダクトで「この結果について」機能を利用できます。 PC 検索 モバイル検索 Google アプリ About this result とは About this result は、検索結果に出てきたコンテンツの掲載元サイトに関する情報を提供する機能です。 2021 年 2 月に米 Google の英語検索で導入されました。 同年 6 月にはすべての国の英語検索で利用できるようになりました。 今年後半には 8 言語へ提供を拡大することを Google は発表しており、そのなかには日本語も含まれていました。 日本語検索の「この結果について」 日本語での「この結果について」機能の利用方法は英語の場合と同じです。 検索結果の縦 3 点ドットをクリック/
サイトの信頼性を調べられるAbout this Result機能がGoogleアプリでも利用可能に #GoogleIO
[レベル: 上級] About this result が Google アプリで利用できるようになります。 Google I/O 2022 の基調講演で発表されました。 公式ブログでも紹介されています。 About this result は、検索結果に出てきたページを提供しているサイトがどんなサイトなのかの情報を提供する機能です。 【About this Result の関連記事】 検索結果の情報源を提供する機能をGoogleが導入、信頼できるサイトからの情報かが検索結果でわかる Google、About this result機能をすべての国の英語検索で導入開始 Google、検索結果のAbout this resultでランキング要因を提供 Google検索のAbout this resultがさらに多くの情報を提供する その検索結果のサイトはどのくらい信頼できるのか？ About
その検索結果のサイトはどのくらい信頼できるのか？ About this resultで提供する情報をGoogleが追加
[レベル: 上級] About This Result で提供する情報を Google は拡充しました。 検索結果に出てきたページを公開しているサイトがどのくらい信頼できるのかを知ることに役立ちます。 About this result は、検索結果に出てきたページを公開しているサイトに関する説明を提供する機能です。 2021 年 2 月に米 Google の英語検索でベータ版として導入されました。 同年 6 月には、米国以外のすべての国の英語検索にも展開されています。 自サイトによる説明、ほかのサイトによる言及、関連する検索結果を追加 導入当初 About this result は、次の情報を提供していました。 Wikipedia での説明 Google が最初にインデックスした日 HTTPS 接続かどうか 2021 年 8 月には、そのページが検索結果に掲載された理由（「ランキング要
Test Your Vocabulary - Result
Most adult fluent English speakers have around 20,000–35,000 words in their vocabulary.
Owner Puts Her Fat Ginger Cat Into Famous Paintings, And The Result Is Hilarious (15 Pics)
Dark mode theme is available exclusively for premium users. Learn more about the benefits of subscribing.
TypeScriptコンパイラの力でResult型のようなエラーハンドリングをもっとシンプルにできるのではという話です。 具体的には、下記のようにメソッドの戻り値をif分で絞り込むだけのコードになります。 Result<T>型を定義したり、isOk メソッドなんかで絞り込みはしません。 const { user, error } = createUesr() if(error) { // user は undefined、 error は CreateUserErrorに型が絞り込まれている。 } else { // user は User、 error は undefinedに型が絞り込まれている。 } 結局Result型は定義するんですけどね try/catchではなくResult型 エラーハンドリングの戦略として、try/catchの他にResult型を使うアプローチがあると思います
Docomo Pacific customers were affected by a cyberattack on March 17, 2023. Sen. Telo T. Taitague gets serious about cybersecurity in her letter to the editor.
Amazon AthenaでQuery Result Reuse（クエリ結果の再利用）が使えるようになりました | DevelopersIO
こんにちは、CX事業本部 IoT事業部の若槻です。 このたびのアップデートにより、Amazon AthenaでQuery Result Reuse（クエリ結果の再利用）が使えるようになりました。 Amazon Athena announces Query Result Reuse to accelerate queries Query Result Reuseを使うと、前回に実行したクエリの結果がキャッシュされ、次回に同じクエリを実行（繰り返しクエリ）した際にキャッシュからクエリ結果が再利用されるようになります。これにより繰り返しクエリの実行が最大5倍速くなり、クエリパフォーマンスが大幅に上がるため、インタラクティブな分析を行う場面などでユーザーの生産性の向上が期待できるとのことです。 使ってみた 準備 事前の環境作成を行います。 まず、Query Result Reuseはversion
Data SDY | Result Togel Sydney | Live Draw Tercepat & Terbaru Hari ini
TSKaigi 2025でのLT資料です
社内の「強い思想を語るLT会」で使用した資料です。 筆者はHaskellやF#、RustなどResult型ネイティブな言語が好みの人間なので、だいぶ偏った見方になっている点はご了承ください。 はじめに みなさん、Result型(Either型)ってご存知ですか？ HaskellやElm、Rust、Kotlin、Swiftなどモダンと言われる言語には大体実装されている型です。 筆者は最近、理想のResult型ライブラリを求めて自作するに至りました。 どんな型？ ざっくり表現すると処理に失敗する可能性があることを示す型です。 （Monadとか細かい話は置いておく） 言語やライブラリによって命名などが微妙に異なりますが、TypeScriptで示すとこんな感じになります。 // どれもやってることは同じ type Result<T, U> = Success<T> | Failure<U> //
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TypeScriptにResult型を導入するための妥協点はどこか？
Result型とESLintでエラーハンドリング漏れを検出する
NeverThrow入門 | TypeScriptでResult型を使いたいんじゃ＾〜
neverthrow で局所的に Result 型を使い、 try-catch より安全に記述する
kotlin-result入門 - ドワンゴ教育サービス開発者ブログ
中途半端にResultを使うぐらいならunwrapの方がマシ
Result型のライブラリを作りました【TypeScript】
Google検索、「About this result」を日本でも提供開始――情報リテラシーを上げるグーグルの取り組みとは？
TypeScriptに安易にResult型を導入しない方がいい - Qiita
result: Do you know motemen? - 日直地獄
byethrow - A lightweight Result type library
TypeScriptでResult型でのエラーハンドリングを通してモナドの世界を覗いてみる - Qiita
Result型で“失敗”を型にするPHPコードの書き方
Google検索、情報源の信頼性を確認できる「この結果について（About this result）」を日本でも導入
TypeScriptの「Result型」のすゝめ
TreeShakableなResultライブラリを作りました
About this resultがGoogleの日本語検索にも導入される、名称は「この結果について」
TypeScript エラーハンドリングにResult型は要らない？
Docomo Pacific outage result of cyberattack
Data SDY | Result Togel Sydney | Live Draw Tercepat & Terbaru Hari ini
Result 型、自前で書くか、ライブラリ使うか
とりあえずTypeScriptの例外処理にはResult型を使っておけ - Qiita
nobita1948.hatenablog.com
anond.hatelabo.jp
blog.domesoccer.jp
automaton-media.com
note.com/tatsuhiroiwamoto
mimoro.hatenablog.jp