Does any1 can tell me how Server.GetLastError work? say i have a case where i have 2 concurrent exception thrown in, and i write a BasePage.cs to inherit into all my aspx.cs page. Then inside my BasePage.cs has a procedure called "protected override void OnError(EventArgs e)".My question is if 2 concurrent exception had occur,how does the SErver.GetlastError() know which is which?
The reason i ask this because inside my BasePage.OnError procedure i have a function to write error to my log file:
ApplicationLog.WriteError(Server.GetLastError());
and i m wondering how .NET handle this issues??
please help thank you.Well, as far as I'm aware (and note that I'm not as handy with exception handling as I'd like to be), the situation you describe can't occur--or at least is so rare that you might be concerned about Earth wobbling off its axis and wandering into Andromeda before it happens.
Is it possible for 2 errors to occur in exactly the same millisecond? Yes, I suppose so. I think, though, as a matter of 'bang for your buck' in terms of your own time spent, you might be better off to code as though you'll never see it.
Then, if by extremely remote chance it does occur, you can spend less time working out whose error is whose than you would've spent trying to anticipate the situation.
Of course, I may be all wet on this--anyone else have any comments?
u r right in away..but precaution better then cure..
anyway..i got it from unofficial source regarding Server.GetlastError();
according to him,"server.getlasterror is thread dependend" which means it "raised for the current request" and if it really happen that 2 concurrent exception is thrown,it will have "will have two different objects".
Well that was from a unofficial source..i m not sure about it i m still looking high n low about it...i spent whole nite looking for it and i m still looking..
Rgd,
Dorris
TheServer object is available from theHttpContext of each ASP.NET page request. Each page request is serviced by a single thread, available from a pool of only 25 worker threads. The chance of two out of 25 threads giving rise to a concurrent exception in the same millisecond is indeed extremely remote. (You are much more likely to cause a concurrency problem yourself, when writing to your application log.)
You might take heart from the introduction toUse Threads and Build Asynchronous Handlers in Your Server-Side Web Code:
"If you look at the documentation for ASP.NET, however, you will find very little information about threading requirements. Does this mean that all threading issues are solved and that ASP.NET developers can live carefree lives building .aspx pages and Microsoft® .NET Framework classes without cluttering their minds with concurrency issues? Well, yes, in most cases it does."
Remember that ASP.NET is a managed environment. It is designed to alleviate the need for developers to worry about most issues of threading, memory management, and so on.
I think you can leave the issue of worker threads to ASP.NET. You, the developer, have some responsibility when dealing with the IO threads ... and you should concentrate your efforts there. (In your case, reading and writing of your application log.)
Say, good answer.
So how're things down under? :)
thank you alot for the great advise.
You're welcome, Dorris.
Jeff, there's a mighty confused wanna-be developer down under ... I can't findApplication Design for Dummies in any bookstore :)
<g
