May 2004 - Posts
Over 400 of you have downloaded Merlin - The Wizard Generator (the 6th most popular in the User Samples Page of GDN!), but I've got almost no feedbakc at all, beside some positive blog entries.
The reason for this can be one of the following:
1. You've downloaded it - but didn't use it. So why bother? Delete it and save disk space!
2. It was so good and perfect, you couldn't find the right words to describe your happiness using it.
3. You did find some problems with it, but you didn't bother to send me a note about it.
Since optimistic developer is a bad developer, I believe reason #3 is the closest thing to the truth.
If that's the case with you - please let me know. I won't be able to fix problems I don't know about. And since I've never met an appliction without any glithces, especially in its first release, I'm sure they are there somewhere, lurking behind the lines, and waiting to jump on the innocent user when he is least ready for them. (Actually, he is NEVER ready for them.)
BTW - I won't resist your feedback even if you're #2 user.
Ashish has posted about his dilemma - whether to throw Exceptions or return Error codes. (His post has disappeared since, for some unknow reason).
We encountered this dilemma also, especially from a developers that have strong background in VB6 (The Java ones had no problems with this).
I think that in order to make the reasonable choice, a clear definition of what is an exception is required.
IMHO, Excpetion is a situation when a piece of code encounters some unexpected problem while running, and couldn't accomplish its task. The emphasis on the “unexpected“ is important, because it eliminates some scenarios that, from first glance, may require throwing an exception, but I think they really shouldn't do that.
Error, in contrast, is a situation when a piece of code encounters an expected problem while running, and couldn't accomplish its task. Again, the emphasis is important. As strange as it may sound, there are expected problems that should be taken care of while running.
Let's look at a sample:
The read() method of the (SQL | OleDB)DataReader. This method returns either true or false. False is returned when there are no more rows to read from. If we'll stick only to the “can't accomplish task“ definition, then the method should throw something like EndOfDataException. But in this case an error code is in order, since this is a (very) expected situation. I mean, you did expect the data to come to its end finally, didn't you?
But - if the connection to the database was terminated suddenly, then this method will throw an exception, since this should not happen, and it is very unexpected (and unwelcome) situation.
If we utilize this definition, we'll find out that the performance penalty of throwing exceptions is insignificant. The application has encountered some unexpected error which it does not know how to handle, and the best thing to do now is write something to log file, close all resources, go to the nearest shelter and pray. Performance are really meaningless in this situation.
It's important to avoid using Exceptions as Flags - “Hey, something happened. Now tell us how to go on.“ For example, In Ashish disappearing post, the following code sample is written:
===========================================================
My application, a web-service reads a string column from the database. 50% of the time this string is a datetime, 50% it’s not. In .net 1.0 /1.1 it is easy for this to lead to code like the following..
DateTime d = DateTime.MinValue;
Try
{
D = DateTime.Parse( string );
}
Catch( InvalidCastExcpetion )
{
// swallow
}
Put this in a loop in a middle tier component ( say processing a recordset ), and load up the server. You’ll generate 1000s of exceptions per second in the asp.net wp, and can easily drop throughput by an order of magnitude. There are a number of internal and external applications I’ve seen coded exactly like this. It’s hard to argue with the correctness of the DateTime.Parse() implementation from a purist pov, but the ramifications can be a lot of money spent on additional hardware by the consumer of the api.
=========================================================================
Couldn't say it better. Again, Exceptions should be used ONLY when something unexpected happened, and the process (the logical one, not the physical) should stop.
There is another reason for not using error codes, and that's the Return Value Type dilemma. When talking about “Error Code”, it's usually a number (eg. -1) or some kind of String. Our method won't necessarily return this type. It may return DataSet, Date, Custom objects or anything else. If we would like to be able always to return error code, and we'll try to utilize it for every problem, even the unexpected ones, each and every function will have to have “Object” as its return type. Another alternative is to have another ByRef argument which will hold the error code, but this will mess up the code and add unnecessary cumbersomeness to the method's interface.
So, to coclude:
When a method has some pre-defined situations when it might won't be able to accomplish its task, it should return an Error Code.
When a method encounters some unexpected problem which prevents it to accomplish its task, it should throw an Exception.
All of the above is, of course, my own opinion, and this is the standard I've taught our developers.
I'll be happy to read your feedback on it.
Yesterday I posted Merlin - The Wizard Generator in the User Samples section of GDN.
Looks like the app is quite a success, and I had a quite positive feedback on it. However, in one of my visits to GDN I saw it was rated one star by someone. Looks like this guy was looking for the source code of the application, which made me wonder - should I supply the code? I couldn't find any formal policy in GDN about whether or not a source code should be provided to the user samples. I've looked into other samples at GDN, and not all of them have the code with them.
Note that I'm not talking about the workspaces, but about the samples.
I don't feel that Merlin's code is ready for release yet (Hey, it's only v0.8!), and I'm not sure I would like to release it when it will be complete, for my own reasons.
Am I missing something? Do you think I should release the code if I post it on GDN? Is there any policy unknown to me that code should be posted with the binary files?
In one of my first posts, I've ranted about the process of creating template in VS.NET, and said I may write some application to automate this process.
Well, time has come. Merlin - The Wizard Generator is a WinForms application that automates the process of templates creation for Visual Studio.NET 2003, and makes it really easy and intuitive (I hope...).
Merlin is hosted on GDN, and that's an opportunity to praise this really great site.
The download bundle of Merlin includes the EXE file and an HTML User Guide.
I will be more than happy to hear any feedback regarding Merlin.
BTW - Roy, I you're reading this - I'm thinking of converting Merlin to an Add-In, and submit it to your contest.
Sometimes I feel a bit confused about the proper usage of "Try...Catch" blocks. The (healthy?) developer instinct is to put it wherever possible. However, I think that an over-usage of it can lead to an unnecessary cumbersomeness of the code, without a real benefit.
Since most of the applications today have some generic error handling at the application level (eg. at the Application_Error event of the global.asax file, on web apps) which usually writes something to a log and redirects the user to a friendly error page, there is no real need to wrap everything with Try...Catch block.
IMHO, we will need to use it on the following cases:
1. When a special action is required for this specific exception, eg. closing connection to the database.
2. When the original exception should be replaced / wrapped in another, maybe friendlier, exception.
In any other case, no such block is necessary. The generic handler will take care of it.
What do you think of it? Am I missing something?
“Mono's creator and leader Miguel de Icaza told internetnews.com that the response to the beta version has been strong, noting that in the first few hours of its release it had tallied over 40,000 downloads.”
from InternetNews.
A few months ago a friend of mine asked me about my opinion of writing Real time apps with .NET. I told him that IMHO it's not a good idea, for various reasons.
Yesterday, in our Bloggers' Dinner, Ido told me that in his previous employer he developed real time apps with .NET, and that sometimes they outperformed native real time apps.
Does anybody in this blogsphere has any massive experience with realtime programming in .NET? How was the experience? Did it really worked so fast? Please drop me a line.
We had yesterday the (first official) Israeli Bloggers' Dinner.
It was really great, and added a “facial” dimension to the so familiar fonts, thoughts and articles.
We had a special guest, Johanna Rothman, a well experienced and extremely educational project manager. It was good to hear that the project management dilemmas we have here in Israel are quite the same as abroad. Looks like the computers really erases the borders...
It was a great opportunity to meet Roy, Ido and Udi, and talk to them by mouth and voice and not by keyboard.
I hope this was a first of many dinners to come.
I succeeded in making my machine usable again, after the crisis I had with the DevPartner profiler.
What I did was to uninstall all the VS.NET and .NET Frameworks I had (2003, 2005, v1.1, v1,2 respectively), and re-install v1.1 and VS.NET 2003. Now everything looks fine.
I sent mail to Compuware support regarding this issue. I hope they'll respond, and make sure it won't happen again.
Things like that make bad reputation for a company's products. Next time I'll have to use one of Compuware products, I'll have second, third and fourth thoughts.
Pitty.
Roy posted about a free edition of the DevPartner Profiler.
I've downloaded and installed it, and the gates of hell were opened. Looks like the tool installs the .NET v1.0 (!) automatically, without checking what there is already on the machine (I had v1.1 & whidbey). Since then, the VS.NET just gone creazy. I can't debug any web application anymore, and I start debugging, I get the following message:
“Unable to start debugging on the web server. There is no managed code running in the process. In order to attach to a process with the .NET debugger, managed code must be running in the process before attaching.”
There is almost no docs about this error message in the web.
what I tried to do until now is:
- Uninstall the DevPartner
- Repair the VS.NET installation
- Reinstall the .NET Framework
- Remove / Create the root application of the IIS
But nothing helps. Of course I tried to attach the process manually after starting with CTRL+F5, but that didn't help either.
THIS DRIVING ME NUTS!
If you know about this message and how to overcome it, please drop me a line. And if someone from Compuware is reading this - please improve your installation process. I found some posts in the internet of other guys who encountered the same problem with your product, but no one found a solution yet.
More Posts
Next page »