アカウント名:
パスワード:
デバッガ「エミュレーション環境でチェックチェック～いけるねうん。OSバージョン別動作とかはまぁ無視して大丈夫でしょ。ﾖｼｯ」配信担当「いけたみたいだね、俺は配信するだけだし。配信GO～～～～ ヨシッ！」
開発担当（ガラっ）「あのー、言い忘れてましたけど今回のバージョンから新しい機能いろいろ付けたんで動作チェックOS別に細かくお願いしますね～」
一同「。。。。。『原因は調査中です、まる』っと。よしっ！！」
本件のissue [github.com]より、
特定バージョン(v1.2.0)より前からのアップデートでデータが壊れ、今回のバージョンでアプリが落ちる。
実機でやってないからとか、OS別にやったからヨシなんてものではなく、真っ新な状態や旧バージョンからアップデート後の状態別にテストが必要と指摘できなければ、同じ穴の狢だろ。
> 特定バージョン(v1.2.0)より前からのアップデートでデータが壊れ、> 今回のバージョンでアプリが落ちる。
いや、そうとも限らないです。v1.2.0を経由していても駄目な場合があるという報告があります。（事実であれば）
あと、データが壊れる、というのもちょっと違うかと。利用規約を読んだ日時を記録するデータがあって、条件によっては、これが最小値（Ticks = 0 : グレゴリオ暦0001年1月1日0時0分0秒）のままになるみたい。（利用規約を読んだフラグだけ立って、日時が記録されていない状態）
最大のミスは、DateTime型への加減算で例外が発生しうることを認識していなかったことじゃないかと。JSTとUTCの変換時に9時間分の減算を行っていて、これが最小値より前の日時になると例外が発生してアプリが止まります。
指摘に「標準のタイムゾーン変換関数を使わないから」というものもありますけど、実はこれも間違い。標準の変換関数を使おうが、最小値より前になれば例外が発生します。
issueに書いてあるけど「例外が発生しうることを認識していなかった」ことが原因ではなく例外が発生する条件となる（最小値設定のコードが実行される）可能性が稀とつまり、デッドコードだと思っていたことが原因
すでにユーザーの端末にはMinValueが入力された状態で記録されてしまっているから、MinValueが入っていた時の迂回処理は必要。修正方法としてcatchを追加するのか、MinValueと同値かの条件分岐を入れるのかは好みの問題でしかないし、「加減算で例外が発生しうることを認識していなかった」の説明にはならない。例外に至るケースには至らないと考えていた場合、静的解析で警告が出ていたとしても、対処不要と判断される可能性のほうが高い。
それと、Javaの検査例外はそういった目的で使うものでは無い。実際、標準ライブラリの日付計算ではチェック例外が必要となってないし、場合によってはオーバーフローし、エラーにならずに望まない処理が行われる。
MinValueと同値かの条件分岐だとMinValue+8時間のときにやっぱり例外で落ちるのでダメですね。
妄想で語るべきでないし、そうして良いと思うならプログラミングはやめるべき。エラーとなった処理はJSTからUTCへの変換で、その処理は8時間減算であって加算ではない。 DateTimeの仕様 [microsoft.com]を読めば明らかが、DateTimeは0001年1月1日0時0分0秒～9999年23時59時59分を表現し、加減算はMinValue～MaxValueの範囲を超える場合に例外が発生する。MinValue(0001/1/1 00:00;00)に8時間を足した程度で、9999年は超えられず、つまり、MinValue-8時間なら例外は投げられるが、君の言う「MinValue+8時間のときにやっぱり例外で落ちる」は発生しない。
というか例外処理は
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
yoshi! (スコア:0)
デバッガ「エミュレーション環境でチェックチェック～いけるねうん。OSバージョン別動作とかはまぁ無視して大丈夫でしょ。ﾖｼｯ」
配信担当「いけたみたいだね、俺は配信するだけだし。配信GO～～～～ ヨシッ！」
開発担当（ガラっ）「あのー、言い忘れてましたけど今回のバージョンから新しい機能いろいろ付けたんで動作チェックOS別に細かくお願いしますね～」
一同「。。。。。『原因は調査中です、まる』っと。よしっ！！」
OSだけチェックすれば良いと思ってるの？ (スコア:0)
本件のissue [github.com]より、
特定バージョン(v1.2.0)より前からのアップデートでデータが壊れ、
今回のバージョンでアプリが落ちる。
実機でやってないからとか、OS別にやったからヨシなんてものではなく、
真っ新な状態や旧バージョンからアップデート後の状態別にテストが必要と
指摘できなければ、同じ穴の狢だろ。
Re: (スコア:1)
> 特定バージョン(v1.2.0)より前からのアップデートでデータが壊れ、
> 今回のバージョンでアプリが落ちる。
いや、そうとも限らないです。
v1.2.0を経由していても駄目な場合があるという報告があります。（事実であれば）
あと、データが壊れる、というのもちょっと違うかと。
利用規約を読んだ日時を記録するデータがあって、
条件によっては、これが最小値（Ticks = 0 : グレゴリオ暦0001年1月1日0時0分0秒）のままになるみたい。
（利用規約を読んだフラグだけ立って、日時が記録されていない状態）
最大のミスは、DateTime型への加減算で例外が発生しうることを認識していなかったことじゃないかと。
JSTとUTCの変換時に9時間分の減算を行っていて、
これが最小値より前の日時になると例外が発生してアプリが止まります。
指摘に「標準のタイムゾーン変換関数を使わないから」というものもありますけど、実はこれも間違い。
標準の変換関数を使おうが、最小値より前になれば例外が発生します。
Re: (スコア:0)
Visual Studio上で開発してればDateTime型変数を演算してる'+'なり'-'なりにカーソルをポイントするだけでArgumentOutOfRangeExceptionが出る可能性をポップアップで表示してくれるんだよなぁ
コンパイラがもうちょっと頑張れば、静的解析か何かでこれ誰もtry catchしてないんだけどいいんすか的な警告出せるんじゃなかろうか。
Re: (スコア:0)
issueに書いてあるけど「例外が発生しうることを認識していなかった」ことが原因ではなく
例外が発生する条件となる（最小値設定のコードが実行される）可能性が稀と
つまり、デッドコードだと思っていたことが原因
Re:OSだけチェックすれば良いと思ってるの？ (スコア:0)
Javaのチェック例外ならともかくC#じゃあそんなのはどんだけ気をつけていても漏れるんだから静的解析で警告出すのが正当だと思うよ。
Re: (スコア:0)
すでにユーザーの端末にはMinValueが入力された状態で記録されてしまっているから、MinValueが入っていた時の迂回処理は必要。
修正方法としてcatchを追加するのか、MinValueと同値かの条件分岐を入れるのかは好みの問題でしかないし、「加減算で例外が発生しうることを認識していなかった」の説明にはならない。
例外に至るケースには至らないと考えていた場合、静的解析で警告が出ていたとしても、対処不要と判断される可能性のほうが高い。
それと、Javaの検査例外はそういった目的で使うものでは無い。
実際、標準ライブラリの日付計算ではチェック例外が必要となってないし、場合によってはオーバーフローし、エラーにならずに望まない処理が行われる。
Re: (スコア:0)
というか例外処理は重いので、事前に条件分岐でチェックできるのならば例外処理を使うのは間違い。
プログラマーならば例外か事前チェックかの選択は明確で実は好みの問題ではないのです。 forループから抜けるのにカウンタがMaxになったときに例外投げたりしないでしょ。
Re: (スコア:0)
MinValueと同値かの条件分岐だとMinValue+8時間のときにやっぱり例外で落ちるのでダメですね。
妄想で語るべきでないし、そうして良いと思うならプログラミングはやめるべき。
エラーとなった処理はJSTからUTCへの変換で、その処理は8時間減算であって加算ではない。
DateTimeの仕様 [microsoft.com]を読めば明らかが、DateTimeは0001年1月1日0時0分0秒～9999年23時59時59分を表現し、加減算はMinValue～MaxValueの範囲を超える場合に例外が発生する。
MinValue(0001/1/1 00:00;00)に8時間を足した程度で、9999年は超えられず、
つまり、MinValue-8時間なら例外は投げられるが、君の言う「MinValue+8時間のときにやっぱり例外で落ちる」は発生しない。
というか例外処理は