I am running a pretty big application, with a few thousand users and I like to check the log files (almost) daily, to see if something has gone wrong.
Fortunately the system is quite stable, but I am having a lot of Invalid CSRF token, Record not found in table X with primary key [NULL], (and so on) errors. I usually ignore that kind of errors, since there is not much that I can do to avoid them.
Is there a way to tell the logger not to save those kind of exceptions in my log files?
Check the Error section of your applications app.php configuration file, specifically the explanation for the skipLog option.
[...]
skipLog - array - List of exceptions to skip for logging. Exceptions that extend one of the listed exceptions will also be skipped for logging. E.g.:
'skipLog' => ['Cake\Network\Exception\NotFoundException', 'Cake\Network\Exception\UnauthorizedException']
[...]
You'd want to skip \Cake\Network\Exception\NotFoundException and \Cake\Network\Exception\InvalidCsrfTokenException.
If you need more fine-grained control, then you'd have to create a custom error handler and override for example BaseErrorHandler::_logException() where you could inspect the exception and act accordingly.
See also
Cookbook > Error & Exception Handling > Error & Exception Configuration
Cookbook > Error & Exception Handling > Creating your Own Error Handler
Related
I'm trying to catch "nrpe unable to read output" output from plugin and send an email when this one occurs and I'm a little bit stuck :) . Thing is there are different return codes when this error occurs on different plugin:
Return code Service status
0 OK
1 WARNING
2 CRITICAL
3 UNKNOWN
Is there a way either to unify return codes of all plugins I use(that there always will be 2[CRITICAL] when this problem occurs), or any other way to catch those alerts? I want to keep return codes for different situations as is(i.e. filesystem /home will be warning(return code 1) for 95% and critical(return code 2) for 98%
Most folks would rather not have this error sending alert emails, because it does not represent an actual failed check. Basically it means nothing more than:
The command/plugin (local or remote) was ran by NRPE, but
failed to return any usable status and/or text back to nrpe.
This most often means something went wrong with the command/plugin and it hasn't done the job it was expected to perform. You don't want alerts being thrown for checks, when the check wasn't actually performed - as this would be very misleading. It's also important to note that the Return Code is not even be coming from the command/plugin.
In my experience, the number one cause of this error is a bad check. And as the docs for NPRE state, you should run the check (with all its options!) to make sure it runs correctly. Do yourself a favor and test both working AND not working states. About 75% of the time, this has happened because the check only works correctly when it has OK results, and blows up when something not-OK must be reported.
Another issue that causes these are network glitches. NRPE connects and runs the check; but the connection is closed before any response is seen. Once again, not a true check result.
For a production Nagios monitoring system, these should be very rare errors. If they are happening frequently, then you likely have other issues that need to be fixed.
And as far as I can tell, all built-in Nagios plugins use the exact same set of return codes. Are you certain this isn't a 'custom' check?
Ok, I think I've found the solution for my problems-I will try to check nagios.log on each node for those errors.
We can use multiple catch block in Try-Catch.
But my Question is : why to use multiple catch blocks when it can be done by using single catch block?
Suppose I want exact cause of my problem, I can get that by Ex.message
If I want to show customized message to user, I can show it by putting If-Else loop on Ex.Message.
Thanks in advance.
To handle the individual exception accordingly.
For example:
If your program is handling both database and files. If an SQLException occurs, you have to handle it database manner like closing the dbConnection/reader etc., whereas if a File handling exception then you may handle it differently like file closing, fileNotFound etc.
That is the main reason in my point of view.
For point numbers 1 and 2:
If showing error message is you main idea then you can use if..else. In case if you want to handle the exception then check the above point of my answer. The reason why I stretch the word handling is because it is entirely different from showing a simple error message.
To add some quotes I prefer Best Practices for Handling Exceptions which says
A well-designed set of error handling code blocks can make a program
more robust and less prone to crashing because the application handles
such errors.
This works only if all exceptions share the same base class, then you could do it this way.
But if you do need exception type specific handling, then I would prefer multiple try-catch blocks instead of one with type-depending if-else ...
You can also ask why do we need the Switch - Case. You can do it with If - Else.
And why do you need Else at all. You can do it with If (If not the first condition, and...).
It's a matter of writing a clean and readable code.
By using single catch clock you can catch Exception type - this practice is strongly discouraged by Microsoft programming guidelines. FxCop has the rule DoNotCatchGeneralExceptionTypes which is treated as CriticalError:
Catching general exception types can hide run-time problems from the library user, and can complicate debugging.
http://code.praqma.net/docs/fxcop/Rules/Design/DoNotCatchGeneralExceptionTypes.html
The program should catch only expected exception types (one ore more), leaving unexpected types unhandled. To do this, we need possibility to have multiple catch blocks. See also:
Why does FxCop warn against catch(Exception)?
http://blogs.msdn.com/b/codeanalysis/archive/2006/06/14/631923.aspx
I'm using C# for end user forms,and what i want to do is to parse the error messages I get from the SQL server.Normally the end user gets the messages like in the picture.Is there a way to parse this and to give the end user what he understands instead of that gibberish there? (like "The Name Test is not permitted in this context .... " as in the picture.)
sql error code
Use Exception.ToString to display a full stack trace. Use Exception.Message to get just the text description part of the error.
In addition, you can look at the SqlException.Class and SqlException.Number properties to make informed decisions about how to handle these exceptions in your code. The SqlException.Number property will correspond to an entry in the sys.messages view. 1205, for example, is the number for a deadlock exception. And if SqlException.Class = 11, then that is a concurrency exception.
The SqlException.Errors property is a list of SqlError objects that contain more detailed information about individual errors. Since a single RPC call to the database can result in multiple exceptions, review these errors to see everything that happened.
exception.ToString() will produce a string like your picture, generally. exception.Message will include just the error message, no stack trace.
When reporting errors in SQL there is always a dilemma where the SQL message needs to convey to the developer what happen, but also provide useful information to a user of the application. We developed a technique of structuring the SQL message into an XML string that provides all the useful information about the error, which allows the caller to use as required. You can see my article on this technique on Code Project at the URL below:
http://www.codeproject.com/Articles/1076477/SQL-Server-Structure-Error-Handling
Salesforce has thrown a new error message at me, and so far I haven't found anything useful in the docs about this. I am trying to save an object in a controller extension, and it does in fact save the record, but instead of returning to the page that I indicate, it shows me the error message "Hierarchy Constraint Violation". In looking over the debug logs, this does not show up anywhere, despite the fact that I log as error any DML exceptions and re-throw them. I am not stifling any other exceptions, either.
I can't tell what this error even means, let alone where it is coming from.
The problem turns out to be an attempt to create a self reference.
An easy one that I am interested in getting your thoughts on:
With your repository implementations, do you like to let exceptions be thrown inside the repository and leave the exception handling to the caller, or do you prefer to catch exceptions inside your repository, store the exception and return false/null?
It Depends.
Do I let exceptions bubble up? Absolutely. But I want this for connection failure, command failures. Whatever you do, don't just hide these, you need to know about them. I prefer my applications to fail as quickly as possible to reduce side-effects and further damage.
I also log exceptions. I use Log4net to help with this. But I like to log exceptions at the source. I will let them bubble up from there.
Return null? If something cannot be found (i.e. looking for something by id and it isn't there), then I return null, not an exception. But there are cases where I could see throwing a new exception when this happens.
Main point: exceptions should be 'exceptional', not the rule. If an exception is thrown, it should be because something is really wrong and you need to fix it.
I usually let exceptions leak, though if I'm in a particularly Enterprisey mood I'll wrap them in a RepositoryException to keep clients from caring about the underlying storage engine.
I would never return false/null instead of an exception, as there's already a meaning behind those values.
In rare cases, you could have a brain-dead storage engine that generates exceptions on non-exceptional cases - and I would catch those specific ones and return null if appropriate (eg., if a row does not exist, but the storage engine throws an error on that case - I'd catch it and return null).