Re: Exception handling?
That is why I say the real issue is the lack of documentation or the
"hidden" knowledge that are wrapped into classes.
When you use fopen(), you know what the possible errors are, basically
invalid file path, error 2
not found, for a already exist mode, error 3
read/write sharing issue, error 5 or 32
but regardless of the error code, the #1 idea is that the FILE *
stream variable is NULL.
Some of the things I am coming across with .NET is that some old
traditional and SOLID concept no longer apply.
For example, opening a file with append mode. Traditionally, the file
is open/creating with a FILE SHARE READ/WRITE mode.
This is not the case any more with .NET. The StreamWriter constructor:
StreamWriter(string filename, bool Append)
opens the file in FileShare.Read mode only.
Whats funny is that I asked this question in MS FORUMS and someone
came back suggestion that 95% scenarios this is expected usage and I
represent 5% scenarios.
I suggested that for C/C++ developers migrating to .NET, it would be a
higher expectation that opening a file or stream in append mode is
atomic and Read/Write Share mode simply because that is what they are
use to.
Anyway, my point here is that in C/C++ I don't need an exception trap
for fopen() based appending which I had to add in .NET to find out
what was going on, and after I found out and changed the code so open
the file first in FileShare.ReadWrite mode and pass this to
StreamWrite, I decided to keep the trap in to cover other possible
sceanario, like OUT OF DISK space :)
--
Giovanni Dicanio wrote:
On 23/06/2010 01:51, Joseph M. Newcomer wrote:
Note that this could be handled as
BOOL TryParse(...args...)
{
try
{
Parse(...);
return TRUE;
}
catch(..whatever..)
{
return FALSE;
}
}
It ain't rocket science. And it isn't clear to me how handling the
exception results in
"bad code".
Sure it isn't (ain't?) rocket science... but do you like a fopen that
throws an exception if the file cannot be opened? No, I prefer one
returning an error code.
The fact that you can't open a file is not an exceptional condition, and
I prefer code like:
if ( some_open_file_api(...) == error )
{
... do what you want... (e.g. create the file, or other stuff...)
}
... normal flow
instead of try/catch.
It was clearly written before: the usefulness of exceptions is inversely
proportional to the number of try/catch you use: if you clutter your
code with lots of try/catch then IMHO you are overusing (abusing)
exceptions.
I think exceptions should be used in *exceptional* conditions (like
David wrote before).
BTW: I like these articles from the OldNewThing blog:
"Cleaner, more elegant, and wrong"
http://blogs.msdn.com/b/oldnewthing/archive/2004/04/22/118161.aspx
"Cleaner, more elegant, and harder to recognize"
http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx
Giovanni
--
HLS