営業:
「なぁなぁ、sk君」
sk:
「なんすか」
営業:
「ロト6当たらへんかなぁ?」
sk:
「いや、頼み事みたいに言われても」
営業:
「当たったらいいや~ん」
sk:
「まぁ確かにいいですね、当たれば。
俺もよく買ってない宝くじ当たらへんかなぁっとか考えますし」
営業:
「買ってないもん当たるかい」
sk:
「買っても当たらないですけどね」
営業:
「俺なぁ、思うんやわ。
神様って忙しいんとちゃうんかと。
でな、俺が祈ったところで神様んとこまで届かへんねやわ。
だから神様に祈るとき両手合わせてお祈りした後にな、
住所と電話番号と名前
を伝えることにしてんねん」
sk:
「末期すね」
このブログを検索
2009年1月30日
2009年1月26日
ExceptionとErrorとエラー処理
- まだだ、まだ終わらんよ!
→Exception - 我が生涯に一片の悔い無し!
→Error
プログラムの流れとしてはこいつらが飛んで来た時に受け止めて何か処理、受け止められなければさようなら。
そいでですね、こいつらを受け止めた際にメッセージか何かを表示させるのが王道だと思うんですが、そこに表示させるメッセージってException.toString()とかそのまま表示させて良いもんなんでしょうか。
正直ユーザーからしたらstd.utf.UtfException: illegal UTF-16 valueなんて表示されても「なにコレ? バカ?」としか思わないんじゃないんだろうか。
組んでる人間も「知るかよ、動けよ」としか思わないわけですし(俺だけか)。
こういった場合に一番良いのは何だろう。
- タイトル:例外発生
メッセージ:UTF-16文字列が不正です
詳細:std.utf.UtfException: illegal UTF-16 value - タイトル:文字列処理失敗
メッセージ:入力された文字列を処理できません。※UTF-16文字列を使用してください。
詳細:std.utf.UtfException: illegal UTF-16 value。 - タイトル:エラー
メッセージ:std.utf.UtfException: illegal UTF-16 value
2009年1月25日
例外とAccess Violation
import std.stdio;
void main() {
Test test;
writeln(test.toString);
}
class Test {
override string toString() {
return "test method.";
}
}
> dmd -run Z:\test.d
> object.Error: Access Violation
頼むからもう少しまともなエラーを出してくれないか、DMD。
インスタンス生成してないことに気付くのに10分はかかったよ。
先頭からこんなこと書いてますが何が言いたいかというと、
Visual Studioが素晴らしすぎる。
DMDだけだと開発効率最悪な感じがします。

あの時このプログラムはどうなって死んでしまったか、といった情報も分かりにくいんでとりあえず-debugではstd.writeでログ書き出し、そしてひたすら追う。
それはそれでD(実質DMDがD言語)っぽいから面白いんですがねぇ…?
はやくIDEが欲しいです。
純正、って言うのもおかしいですがD専用のIDEが。。。
2009年1月23日
2009年1月19日
仕事場でのRDPが革命過ぎて窓際一直線
最近家に帰るのが早くて20時には帰宅しています。
いや~、仕事が無いってのも疲れるなぁ。
今年度の前期が嘘のようですよ。
で、帰宅が早いのでネムぃに取り組む時間が増えました。
ちょっと贅沢にメモリを使いまくって快適にプログラミング、
のはずだったんだけど詰んだ。
もう精一杯詰んだ。
@文字列
ああ、わかってるさ。
Dの文字列が0終端じゃないってことくらい十二分に分かってるよ。
むしろ変に理解してたから駄目だった。
ネムぃの内外(D部分とWin32API部分)の橋渡しはTextって構造体が担当してるんだ。
省略して書くと
こんな感じで内部に ptr ってメッソドがあるんだ。
こいつが駄目だった。
text配列とnullを結合してたんだ。
コレで大丈夫だと思ってたんだ。
ここで0終端文字列を作ってると思ってたんでこいつをあっちゃこっちゃに使ってたんだ。
一通りの基盤部分が作り終わってメインウィンドウだけの結合をやってみる。
アイコンハンドル取ってくる関数でやたら落ちたりメニュー表示文字列がゴミつきだったりと散々なことに。
アイコンハンドル取得してるところは失敗したときに例外投げるようにしていてまだぜんぜんcatch書いてなかったので落ちても構わなかったんですが文字列にゴミが付くのはいただけない。
2-3時間ひたすら目で追ったりstd.stdio.writeしたり-covしたり。
でもね、writeで書き出される文字列はText構造体を表示させてたので当然引っかからない。
もう最後の望みを掛けてText構造体にメス入れ。
ゆっくり見直して text ~ null に違和感を。
あれ? この null ってホントに 0 なのか?
空配列っぽくね?
ああ、修正したら直ったさ。
アイコンハンドル取得するところもアイコンアドレスにゴミ混じってたから落ちてただけさ。
@GC
もはや何も語るまい。
いや~、仕事が無いってのも疲れるなぁ。
今年度の前期が嘘のようですよ。
で、帰宅が早いのでネムぃに取り組む時間が増えました。
ちょっと贅沢にメモリを使いまくって快適にプログラミング、
のはずだったんだけど詰んだ。
もう精一杯詰んだ。
@文字列
ああ、わかってるさ。
Dの文字列が0終端じゃないってことくらい十二分に分かってるよ。
むしろ変に理解してたから駄目だった。
ネムぃの内外(D部分とWin32API部分)の橋渡しはTextって構造体が担当してるんだ。
省略して書くと
struct Text {
/// 実態。
wchar[] text;
}
こんな感じで内部に ptr ってメッソドがあるんだ。
こいつが駄目だった。
struct Text {
wchar[] text;
wchar* ptr() {
return (text ~ null).ptr;
}
}
text配列とnullを結合してたんだ。
コレで大丈夫だと思ってたんだ。
ここで0終端文字列を作ってると思ってたんでこいつをあっちゃこっちゃに使ってたんだ。
一通りの基盤部分が作り終わってメインウィンドウだけの結合をやってみる。
アイコンハンドル取ってくる関数でやたら落ちたりメニュー表示文字列がゴミつきだったりと散々なことに。
アイコンハンドル取得してるところは失敗したときに例外投げるようにしていてまだぜんぜんcatch書いてなかったので落ちても構わなかったんですが文字列にゴミが付くのはいただけない。
2-3時間ひたすら目で追ったりstd.stdio.writeしたり-covしたり。
でもね、writeで書き出される文字列はText構造体を表示させてたので当然引っかからない。
もう最後の望みを掛けてText構造体にメス入れ。
ゆっくり見直して text ~ null に違和感を。
あれ? この null ってホントに 0 なのか?
空配列っぽくね?
struct Text {
wchar[] text;
wchar* ptr() {
return (text ~ cast(wchar)0).ptr;
}
}
ああ、修正したら直ったさ。
アイコンハンドル取得するところもアイコンアドレスにゴミ混じってたから落ちてただけさ。
@GC
もはや何も語るまい。
登録:
投稿 (Atom)