teratailに質問して回答がつかなかった質問が2つあります。
上記の質問はなぜ回答がつかなかったのか、どのように質問していれば回答がついたのか。
今後のために、よろしければご指摘をいただけませんでしょうか。
気になる質問をクリップする
クリップした質問は、後からいつでもMYページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2018/04/27 02:25
回答7件
0
TSの方、回答してみました。
回答したモチベーションは、TypeScriptの質問に回答してみたい!というものでした。
当該質問は、読むのが少し大変でした。
理由として考えられるのは、
- 序盤に、回答者にとっていらない情報が多め
前提条件、もっと減らしたいところです。前提条件最初の注釈は気持ちは分かるのですが、ちょっとノイズです。これは「背景」という項を立てて、最後にかいてはどうでしょう。またSentryとか言ってしまうと、「TypeScriptかつSentry」な人じゃないと見たくなくなります。自分のピンポイントな目的に絞って質問した方が読みやすそうです。 - 結局どうしたいかが読み取りづらかったです
動けばいいのか、作法を知りたいのか、etc...。「3つのうちどれがいいですか」といっても、観点がなかったので。作法を知りたいのであれば、コードも文もより簡潔に、かつ比較しやすいよう似た形に並べたほうが良いです。参照元のコピペになっていて、本質と異なるノイズが多く感じました。(sayHelloとかいらないんですよね?)
という感じです。
偉そうな文になっているところあるかと思いますが、ご容赦いただきたく存じます。
投稿2018/04/27 05:07
退会済みユーザー
総合スコア0
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2018/05/02 07:24
0
私にはこう見えましたという点しか答えられませんが、何人か回答があればそれなりのものになると思い回答します。
問いが明確でない。
なんとなく直してとお願いしているんだけどどこを気にしているのかわからない。
情報が多すぎる。
かなりそのままのコードが乗っているので、腕まくりしないと回答できない。回答者は私も含め酔っぱらって話し相手を求めているおっさんよりましな程度の人が多い印象です。もう少し単純化させた方が良いと思います。
回答しても他の人が見ない
趣味でやっていることなので、純粋にコードの書き方のテクニックであれば喜びますし、ピンポイントの質問であれば、”これに応えられる俺すげぇ”といった感じで回答ができます。質問者だけに回答するのであればお仕事と同じだと感じます。
投稿2018/04/27 02:52
総合スコア2883
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2018/04/27 09:11
2018/04/27 09:31
0
- 内容が専門的で回答できる方がいらっしゃらない
- ソースコード全貼りは、コードレビューの手間がしんどいので回答したがらない
今回の場合、上記の2点が該当するかな、という印象です。
どう改善したらいいか、は、難しいですね。。。
内容が専門的なのはどうしようもないですし、全貼りじゃなく一部だったら意味が通じなくなるでしょうし。
投稿2018/04/27 02:19
総合スコア7196
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2018/04/27 02:25 編集
2018/04/27 02:56
退会済みユーザー
2018/05/02 07:25
0
ベストアンサー
改善点
上記スレで改善できる点は下記の通り。
- 質問の見通しが悪いと思いました。
(Typoraのようなアウトライン表示できるmarkdownエディタなら一定の合理性がありますが、teratailでは読みにくくて仕方ありません。) - 「前提条件」が多すぎると思いました。他の方がコードを書く上で不要な情報は極力排除すべきと思います。べき論であれば、メリット/デメリットで事実が伝われば十分です。
以上を踏まえた質問文案を下記に示します。
質問文案
質問
TypeScriptでカスタムエラーの3つの実装方法を記載しました。
自分ならXXXなのでこれを選ぶ、あるいはもっといい方法があるというようなご意見をいただきたいです。
コード
TypeScript
1/** 2 * (1) Errorをimplementsするクラスを作成する 3 * @url https://books.google.co.jp/books?id=8m5qBgAAQBAJ&lpg=PP1&dq=isbn%3A4798139807&hl=ja&pg=PA195#v=onepage&q=ApplicationError&f=false 4 */ 5class ApplicationError implements Error { 6 public name = 'ApplicationError'; 7 8 constructor(public message: string, public code: ApplicationErrorCode) { } 9 10 toString() { 11 return `${this.name}: ${this.message}`; 12 } 13} 14 15/** 16 * (2) Errorをextendsするクラスを作成する 17 * @url https://github.com/Microsoft/TypeScript-wiki/blob/master/Breaking-Changes.md#extending-built-ins-like-error-array-and-map-may-no-longer-work 18 */ 19class FooError extends Error { 20 constructor(m: string) { 21 super(m); 22 23 // Set the prototype explicitly. 24 Object.setPrototypeOf(this, FooError.prototype); 25 } 26 27 sayHello() { 28 return "hello " + this.message; 29 } 30} 31 32/** 33 * (3) Errorをカスタムするのではなく,throwをカスタムしてすべてErrorを使用する 34 * @url https://www.htmlhifive.com/ 35 */ 36 37/** 38 * フレームワークエラーを発生させます。 39 * 40 * @private 41 * @param code {Number} エラーコード 42 * @param msgParam {Any[]} フォーマットパラメータ 43 * @param detail {Any} 追加のデータ(内容はAPIごとに異なる) 44 */ 45function throwFwError(code, msgParam, detail) { 46 47 ..... 48 49 if (code) { 50 e.code = code; 51 } 52 if (detail) { 53 e.detail = detail; 54 } 55 56 throw e; 57}
各手法のメリット/デメリット
-
Errorをimplementsするクラスを作成する
-
Errorをextendsするクラスを作成する
-
Errorをextendsするクラスを作成する
手法 メリット デメリット 1 アプリケーションの例外とJSの例外が分別できる( ネイティブのError 型は聖域として扱い、この種の例外を決してスローしないようにしよう。カスタム例外をApplicationError クラスのサブクラスとして作成すれば、本当に例外的な状況においてコードの外側で使用するためにError型を取っておくことができる。) スタックトレースが取れない。 子クラスを作るたびにnameを書かないといけない(何らかの方法で解決できるのかもしれないが自分は分からない) 2 スタックトレースが取れる Object.setPrototypeOf
を忘れたり誤ったりするとinstance instanceof FooError
がfalseになる。 TypeScript, Javascriptの仕様変更によって壊れる可能性が1より高い(実際にTypeScript2.1で壊れた)3 全てのエラーはErrorなのでインターフェースが統一されている。 codeがenumであればdiscriminated unionsによって型の推論ができる。 TypeScriptだとグローバルのError型定義を拡張しなければならない。 使用する側が気を付けなければならない。
前提条件
- Javascript(TypeScript)では極力例外を投げるのは避けるべきとは思っている
- サポート対象ブラウザはChrome,FireFox,Safariの最新版のみ。デバイスはPC, タブレット, スマートフォン。
- TypeScriptを使用したSPA. ソースコード50000行ほど、ファイル数680 今後2倍くらいになりそう
- フロントエンド監視にはSentryを使用している
- JavascriptのErrorを拡張して,エラー種別の判別とSentryでのバグトラッキングに活かしたい(エラーコードを設けたり、エラー種別によってエラーハンドリングを変えたり)
(※ここはどう省略すべきか不明な為、オリジナルのままです。)
Re: u28epGUsk さん
投稿2018/04/29 15:13
総合スコア18189
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2018/05/02 07:21
あなたの回答
tips
太字
斜体
打ち消し線
見出し
引用テキストの挿入
コードの挿入
リンクの挿入
リストの挿入
番号リストの挿入
表の挿入
水平線の挿入
プレビュー
質問の解決につながる回答をしましょう。 サンプルコードなど、より具体的な説明があると質問者の理解の助けになります。 また、読む側のことを考えた、分かりやすい文章を心がけましょう。