I have a Flex 3 app which I want to instrument to report errors generated by the app to a server via simple HTTPService call.
My idea is to wrap all the methods in try ... catch blocks which then pass the Error object to the reportError() function (which then fires off the HTTP request and pops up a dialog) but is there a better way?
I have implemented a system such as the one you suggest, wrapping all of my methods in try/catch and sending the stack trace to a service that emails me the errors. I created a basic format for the error that logs which method the error occurred in. I noticed that sometimes I end up getting null from the stack traces, so I wanted to log that information for these situations.
It GREATLY improved my application. I tracked down a (large) handful of errors and released a much cleaner build to my users. Now I don't ever get the emails.
The better way IMO is something like this.
I've no idea how good is this particular project (aside from this spooky GPL license), but I don't see why logging in action script should be any different from J2EE, C++, or say Python. Yes, it has some sand box security issues, but I think if this solved, you could log into some centralized log server..
Unfortunately, there really isn't -- errors don't bubble up in such a way as to be trappable at a global level, so the only real way you have to catch errors is to try and catch them all manually. (The community's been pretty vocal in asking for a global exception-handling feature for a while, but it's not there yet.)
Related
I am looking for a way to log ajax errors globally. I have already read numerous ways but none of them worked. The problem is that when an error occured in ajax requests it gets handled by the RestHandler.ExecuteWebServiceCall and never triggers Application_Error.
It is well described here by #Michael Liu .
The problem with his answer is that there is no way to get the actual exception and log it if you have customErrors option set to On in webconfig.
Note that i don't want to return stack traces to javascript or anything like that. Also the app is very old and big and i am not able to change the entire system of how soap or ajax or logging works as it would be a high risk of breaking the app.
Is there any way to catch and log these exceptions globally?
Thanks in advance.
I am trying to maximize the benefits from an experience.
Also I usually use Enterprise library logging block, I log errors and a portion of statistical information into the database, because it is centralized place to track errors, if database logging failed, Normally it goes to Event Log.
Tracing messages should go into file:
Which choice you believe we should go
1- Only Some tracing messages can be left in code if there is a complex algorithm or unstable module.
OR
2- We should not keep any tracing messages in code, clean it up as soon as bug is resolved.
For database.
I think that Errors raised from SP and functions should be logged into another table in the database, and that exactly what is done by AdventureWorksLT2008 database.
Is it a bad idea to log database events directly to Enterprise library Log table without raising this errors to next tier. I think it is more fixable, because I can put more custom information in the message. of course some errors will not be handled and will reach the next tier.
Any ideas, or comments, something else you do. something you want to clarify.
Thanks
Are you talking about catching errors and logging directly in T-SQL and not then doing RAISERROR to get it to the caller?
I think that's a viable strategy for certain kinds of issues - for instance, if an SP wants to find a problem and correct it silently and simply issue a warning.
But the kind of issues it would apply to might not be terribly frequent.
The kind of things I would think about are things like unusual cases where unexpected UPDATEs are done instead of INSERTs? Or where data already exists so is not generated. Or in a deployment or build script which skips an existing table, etc.
What if your database has performance issues and SP/functions start timing out - logging the error to the database may not work?
I'm getting the following error on my production servers:
Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
It doesn't happen all the time, but seems to happen most frequently during times of high traffic.
The error is occurring in a custom IHttpHandler.
The stack trace doesn't give much of an indication of what's actually going on when the exception happens - all that is happening in the area it indicates is writing to the response using Response.Write.
I've noticed that when this starts happening, if I remove the traffic from the server, recycle the app pool, and put it back on, it seems to help. Though, when the traffic is first returned, there is a cluster of these errors before it begins working properly.
I've also taken a look through the dozens of other SO questions/ google search results with this error, but none of the remedies seem to be relevant to this situation.
Edit: I don't do anything directly with unmanaged/unsafe code. I do use MEF though, and I'm not sure if it does.
No, this is not a serverfault issue. It's clearly a programming issue.
What is that IHttpHandler code actually doing? Is it interacting with any unmanaged code?
BTW, the exception message means what it said.
Is your custom handler managed? This message usually indicates that the problem is with the unmanaged code - corrupted pointers and the such.
I have seen this occur when the app pool is recycling under heavy load and the memory being used as already been flushed and released, but the reference to it still exists. Is the IHTTPHandler doing anything with P/Invoke or unmanaged/unsafe code?
It is very likely it is related to the fact that ASP.NET is a multithreaded and you use non-thread safe code in the IHttpHandler.
Probably one of these:
COM objects (e.g. Excel, Word automation or similar)
Native Win32 API (P/Invoke)
So you need to provide more info on what exactly you do in the handler.
In my Project (ASP.NET, VB.NET), sometimes a Server Error is showing.
When this error is shown, Users cannot submit their Applications, so that they have to re-type full details and submit again.
How can I escape from these Server Errors?
I think the reason may be Memory issues. Because if the user try to submit again (after Sign Out->Sign In ) then they can submit. Daily twice or thrice Error is happening.
The word "Server" in the phrase "Server Error" refers to your ASP.NET code. You are the server!
If you are running .NET 2.0 or later, you can look into the Application event log (use the Event Viewer applet) for warnings from "ASP.NET". They will include details of what went wrong.
You need to debug your code to find out what's causing this, but the event logs will give you a starting point.
"Server Error" is just a generic message that indicates the the server code (your code) threw an exception that wasn't handled. It shows the user "server error" instead of a specific message so that no implementation details are exposed to outside users.
In other words, without debugging or looking at a log file or something, all you can tell from "Server Error" is that an Exception of any type was thrown.
Sorry, but the information you provided is not helpful in determining the issue.
I think that you'll need to provide a bit more info to get meaningful solutions.
Do you have server logs?
Can you debug through the app as the error occurs?
Does the error occur at a certain time of day, or after a certain regular action?
Does your app attempt to write to a file that may not be accessible?
is it possible that you are experiencing memory issues?
the list could go on, best to do some more investigation and if a more specific issue comes to light edit your question with the extra detail.
AFTER EDIT:
From the extra detail you've provided I wouldn't jump to memory as an issue, in signing out and back in the user is refreshing their session so everything is reset. If you are not seeing anything in your logs you'll need to look at your exception/error handling.
You just haven't provided enough info yet for us to work out the root issue, let alone suggest a solution. That's what you're seeing from all the answers here thus far. Find the event log info and there should be something there to help you, or at least something more to post here.
Try debugging the error? Server Error can be caused by various reasons.
Check for potential infinite loops.
Check for code in the constructor that might fail (especially for web services).
I think I've had cases like this which led to 'Server Error'. I'm assuming you mean the big red 'Server Error' message?
Save all your files and close your Visual Studio and now right click on Visual studio and run as administrator. It worked for me.
For Asp.net web applications, is it best to:
trap errors within sql stored procedures and test for a return value in the code or
just let the error occur in sql (dont handle it) and rely on ado.net raising the errors within the code.
What are the best practises here?
A general rule that applies here is to catch the error as near the source as possible. SQL Server now has "try ... catch ..." error trapping syntax. So use it. The overhead of the little bit of extra code is insignificant, and if you have multiple statements in your SP, you can adapt the string in RAISERROR to help localize the problem.
In the interface, it shouldn't be difficult to trap the SP error event and handle it the same way you handle other error trapping in your procedural code.
This is one of the more neglected "best practices" in stored procedures, and it's even more important than in "regular" code because it's trickier to use a step=through debugger.
One useful pattern is to handle this in your SP the same way you it expect it to be handled in any other opaque SDK library.
According this article, this is a type of "boneheaded" exception - i.e. if an error occurs in the SP, this means that there's something wrong with the SP or the data itself.
My advise would be to trap the error in aps.net, as there you have much more possibilities to log the error, as well as all the parameters passed to the SP in order to investigate the problem.
I use try/catch on all potentially error generating calls to libraries or other servers including database queries. I'm primarily a developer not a DBA so I handle the error in the language that I'm most proficient in, C# not SQL. I'm sure that'll vary for every programmer. Not handling the error is never fine in my book.
I prefer both -
the stored procedure calls RAISEERROR, which manifests as an exception in ADO.NET
the stored procedure returns an error code, in case one sproc is calling another
in general, I always make db calls inside a try-catch
The most likely failure mode in the data layer is bad user input vales such as requesting a record that doesn't exist. Most other errors are caused by defective code and usually are caught right away when testing. I like to catch the db error and and always throw a custom error with more information about the data and context of the request. Then the error bubbles back up the call stack and if it was a user correctable error I can alert them to that fact. Otherwise the central error page handler for the application will be called when the error reaches the top of the stack. The worst thing to do is to catch an error and not let it bubble back up. Return codes are outdated constructs unless talking to com components or foreign systems.
Ideally, your web application isn't aware of the back-end or data access. So it shouldn't be handling sql-related errors - those should be handled by the data access layer. But the web application needs to handle failure gracefully, by providing the end-user with a friendly message.
I would say it depends on what you are doing in your stored proc and what you want to do with certain errors that occur. Sometimes I handle it in the sp but other times i let it raise up to the data layer code.
Bear in mind, sometimes you can miss errors when using sql server 2005 try/catch, see my post on this. Whereas, in code (C# in my case) you can access all the errors in the SqlErrorCollection object.
Just be absolutely certain that your error handling in the stored procedure is well thought out and any uncertainties are left to be passed up to the data layer code where you must log everything.
The answer is that you need to do both. Some errors are actually triggered downline from the Database engine. Their source varies, of course, according to the actual way you connect to the database (OLBC, OLEDB etc). You've got to find a way of dealing with these. Some errors such as Deadlock errors out to be handled at the application level too.
As well as errors, it is a good idea to receive and deal with messages from the SQL Server Database Engine. These are very similar to errors and can give the application a lot of useful diagnostic information. If you’re using System.Data.SQLClient, you’ll need to create a SqlInfoMessageEventHandler delegate, identifying the method that handles the event, to listen for the InfoMessage event on the SqlConnection class. You’ll find that message-context information such as severity and state are passed as arguments to the callback, because from the system perspective, these messages are just like errors.
I hope this helps!