エラー処理とログ出力
ソフトウェアの開発において、エラー処理は、時には本来の機能よりも重要です。業務として開発するソフトウェアでは、本来の処理を行うためのコードよりも、エラー処理のコードの方が量が多くなることも良くあります。 ところが、実際のソフトウェアの開発では、エラーをどこでどのように出力するかについては、実装者任せになってしまうことが多いようです。ソフトウェア設計書を見ても、エラーの出力については記述されていないことも良くあります。実装が終わってから、最後に慌しくエラーの出力を組み込むこともあります。 エラー処理について考えてみると、たくさんの難しい問題があることが分かります。これらの問題を理解した上で、きちんとエラー処理の仕組みを考えないと、ソフトウェアの設計や品質にも、重大な影響が及ぶかもしれません。 エラー処理とログ出力は、本来、どのようにして行うべきなのでしょうか。 エラーを知らせる仕組み ソフト
技術コラム
Windowsで、ファイルを開いたり、ファイルに保存したりする時は、いつもおなじみのファイルダイアログを使います。このファイルダイアログは、MFCではCFileDialogというクラスとして提供されており、誰でも使うことができます。 ですが、このファイルダイアログには、不思議な動きをする問題があります。こうした問題の原因や解決策を考えるのは、ソフトウェア技術者にとって良い頭の体操になります。 ................ 続きを読む インターフェースを使うと、クラスやメソッドの再利用性が高まります。 しかし、インターフェースを使うのは、コードを再利用するためだけではありません。たとえ再利用しなくても、敢えてインターフェースを作ることもあります。むしろ、再利用するか否かに関わらず、インターフェースを使うべきだ、という考えもあります。 ここでは、インターフェースの存在意義について考えてみま
リファクタリングにおけるC言語プログラマーの視点
には、ファイルのコピーをするCFileCopyというクラスを例に、メンバー関数が多すぎるクラスを手直しする例が紹介されている。 だが、この例を見ると、リファクタリングによって、不適切なインターフェースを持つクラスができてしまっている。 まずは、手直しする前の、メンバー関数が多過ぎるCFileCopyクラスを引用する。 class CFileCopy { typedef bool (*UserCancelFunc)(const CFileCopy&,void*); typedef void (*DirDownFunc)(const CFileCopy&,const char*,void*); typedef void (*DirUpFunc)(const CFileCopy&,const char*,void*); typedef void (*FileCopyStartFunc)(cons
ソフトウェア工学 (吉田誠一のホームページ)
Abstract Factoryパターン Adapterパターン Bridgeパターン Builderパターン Chain of Responsibilityパターン Commandパターン Compositeパターン Decoratorパターン Facadeパターン Factory Methodパターン Flyweightパターン Interpreterパターン Iteratorパターン Mediatorパターン Mementoパターン Observerパターン Prototypeパターン Proxyパターン Singletonパターン Stateパターン Strategyパターン Template Methodパターン Visitorパターン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
