I've encountered a strange thing. I have configured exception handling in struts 2.1.8 like stated here, only that I redirect to an action instead to JSP (to send emails...).
So, in the action I have
ActionContext ac = ActionContext.getContext();
String stackTrace = null;
if(ac.getValueStack().findValue("exceptionStack") != null) {
stackTrace = ac.getValueStack().findValue("exceptionStack").toString();
} else {
stackTrace = "Stack trace not found!";
}
I had to make this if-else because sometimes the value is null. I haven't found the difference why sometimes I get the stack trace and sometimes I don't. All the errors happen in Struts2.
Did anyone had similar problem? Can anybody directs me where is the problem?
if you map exception with chain result type you'll keep the same request and so the same ValueStack.
First, ValueStack is per-request (each thread has its own), so redirecting to a new action will cause you to lose any data you had in the previous request's ValueStack.
With that said, what is your goal here? The link you provided explains how to map different types of exceptions to custom error pages (or results). Why doesn't that work for you? You mention you want to send emails -- are you sending an email notification about the actual exception (and stack trace)?
If you can expand a bit about what you are trying to do, then perhaps we can give you some guidance.
Related
We have UseExceptionHandler (handle Exeptions) and UseStatusCodePages (handle StatusCode). Why in ASP.NET Core MVC we using StatusCodeResult than just handy extend Exception?
UseExceptionHandler is generally used to catch up unexpected errors and preset them in a more friendly manner to the user.
Whereas status codes are more important in REST API to signal the client the success or failure (and specific cause of the failure) of the specific operation.
Controller action should never throw exception and access a specific resource (i.e. db record) which doesn't exist you should return 404 (not found). When passed data is invalid rest apis return "400 bad request", on success 200. When new resource is created 201 (with "Location" header which contains the url to the new resource, see CreatedAtAction method of the controller class).
With views it works differently where you render the error directly into the HTML Code. You can also return status codes with MVC-esque view controllers and handle it with UseStatusCodePages (i.e. showing a generic NotFound.cshtml template for resources which don't exist).
Also your question sounds like you want to use exceptions to set status code, this is wrong for a couple of reasons.
Exceptions should be (as their name suggest) exceptional; Read: when something unexpected happens. For example if you try to withdraw a negative balance from your bank account and further processing it makes no sense or becomes impossible.
When you expect an error, you should return a result or handle it differently. For validations you should use Result classes (i.e. IdentityResult from ASP.NET Core Identity, which contains a Success property and a property which contains a list of error messages in case the operation or the validation fails).
Throwing and catching Exceptions is quite expensive, so they should really only be thrown when (as pointed above) something unexpected happens. Not finding a record is nothing unexpected.
(Ab)using exceptions for flow control (deciding which code path to execute) is just wrong. That's what if/switch and patterns like strategy pattern are for. Exceptions will just make the code unreadable and harder to maintain.
We are using the MSXML2.ServerXMLHTTP60Class to make HTTP requests. Usually this works fine, but on some occasions when the url cannot be resolved, the send method fails. In this case an exception is thrown.
The problem is that we program in Microsoft Dynamcs NAV C/AL code. This language does not support error trapping (try catch).
Does anybody know if there is some setting in the ServerXMLHTTP60Class that prevents the send method from failing?
Note: the send method fails, so checking the response status is not an option.
Thank you!
Depend your on version of Nav you have different ways to handle exeptions.
In Nav 2016 there will be try function
In previous versions you should use if codeunit.run then syntax to catch the exception and getlasterrortext to get error message.
For more information read Vjeco
Another option to avoid unhandled exceptions is to write a wrapper class around ServerXMLHTTP60Class that will catch all exceptions and handle them in the way you like.
What is the difference between throw new Error and using Meteor.Error()? Is it simply that throw new Error will not be shown to the client, only on the server (the client will get a 500 Internal server error); and Meteor.Error will be sent to the client.
Are there any more differences? E.g. Does one break out of Fibers, stops downstream code?
The main thing with Meteor.Error is like you mentioned
A full stack trace (may not be given by Error always)
Possibility to send the error down to the client, in a limited non revealing form.
Hide the error from the server in certain cases (if its thrown in a method or publish method, and from hooks such as Accounts.onLoginAttempt)
The objects inside are EJSON serialised so a variety of data can be sent down to the client
When a Meteor.Error is thrown, because of the EJSON serialisation you get a bit more information on the server side.
Meteor displays the errors better.
Often you can get [Object object] as the reason to be displayed from ordinary errors when they come from ordinary Errors, from Meteor.wrapAsync
Theres not much else that's different, Meteor.Error is a a subclass of Error with the above changes.
So they'll both stop downstream code. When it comes to Fibers, if the ordinary one is thrown out of a Fiber in any way its likely to stop your app (on the server side & not in a method, startup, Meteor.setInterval, publish, etc)
Its definition is also quite small: https://github.com/meteor/meteor/blob/devel/packages/meteor/errors.js
I've run over a somewhat little problem over the week. The error message upfront this is about:
[30-Dec-2012 15:19:32] PHP Fatal error: Exception thrown without a stack frame in Unknown on line 0
I think it is because my error handler (see below for details) is turning any error into an exception. I might should prevent that in case there is no stack frame.
Is there an easy way to find out if there is any stack frame or not in PHP?
Details:
On one of my websites I've got an error handler running that is turning every error into an exception, the common ErrorException to be precise.
I introduced it some time ago because the site is mainly legacy code and I wanted to have any issue result in an exception I can finally "catch" in a streamlined fashion an exception handler and give the request a stop.
I put this into class of it's own, the handler is registered and also in parallel an output buffer is opened to catch the output up until the exception is thrown. Basically code like this:
// register output buffering
$r = ob_start(array($this, 'handleBuffer'));
// register error handler
$this->_originalErrorHandler = set_error_handler(array($this, 'handleError'));
// register exception handler
$this->_originalExceptionHandler = set_exception_handler(array($this, 'handleException'));
This worked all fine and dandy until I decided to add another output buffering class into the mix. Just one that catches as well all output and then can do some "post production" on the website, including checking for HTML problems (yes, it's all a bit legacy so actually this is a bit duck-taped, I know). That also worked very fine btw. however not when I made a mistake in the new component:
[30-Dec-2012 15:19:32] PHP Fatal error: Exception thrown without a stack frame in Unknown on line 0
This is basically my problem. Is there an easy way to prevent getting these errors? I somewhat know why the error is given but I'm not so entirely sure so it's hard for me to really circumvent the problem. I tried to release the new output buffer before the script enters the new shutdown phase because I thought this would cause this. But this didn't make it.
Your problem indicates that you are using an EOL (End Of Life) version of PHP (specifically PHP < 5.3.0), which means it's no longer supported. This issue comes from throwing an exception where no strack frame exists and as such the old engine did not know how to handle those exceptions properly.
This can be due to a couple of different reasons. Some of the most common ones are as follows:
You threw an exception from inside an error handler or exception handler.
You threw an exception from inside a destructor.
You threw an exception from inside a callback (like an output buffering callback function).
Here's an example that demonstrates your problem under some of those circumstances...
function myErrorHandler($errno, $errstr, $errfile, $errline)
{
throw new ErrorException($errstr, $errno, 0, $errfile, $errline);
}
function myExceptionHandler($exception) {
echo "We got an exception with message: '{$exception->getMessage()}'";
}
function myCallBack($contents) {
trigger_error('ohnoes!'); // You can't throw an error from the output buffer callback function in older versions of PHP < 5.3
}
class Foo {
public function __destruct() {
trigger_error('ohnoes!'); // You can't throw an error from a destructor in older versions of PHP < 5.3
}
}
set_error_handler('myErrorHandler');
set_exception_handler('myExceptionHandler');
The above code would cause you to see the fatal error you described here...
ob_start("myCallBack");
... and here...
$foo = new foo;
This problem has been fixed in PHP >= 5.3.0 so you should not see this issue if you were using the most current version of PHP.
The simplest fix is to upgrade your PHP. If that is not an option you must consider these facts that you can not throw exceptions where PHP does not expect them to be thrown (in callback functions, error handlers, exceptions handlers, etc... -- which are actually all considered to be callbacks to PHP).
The other thing is you should not be turning every error into an exception in this way. If what you are doing is as the code I supplied demonstrates (i.e. throwing an exception from inside the error handler -- thus turning every error into an exception) then you are going to cause yourself a lot of pain and with virtually no benefit. PHP errors are not meant to be handled. They are meant to inform the client of a problem (the client being the person writing the PHP code), or potential problem. Handling the error itself is not as simple as turning every error into an exception and then handling that exception, because not every error should be exceptional. For instance, E_NOTICE level errors have no place in exception handling. They are primarily used to notify you of a potential for a bug, not that there is necessarily something buggy with your code and not to mention that most of them can't even be handled easily in user-space code (they mostly require re-factoring the code itself). I strongly advice against this poor practice.
I'm running two glassfish v2 domains containing stateless session EJBs. In a few cases, an EJB in one domain has to call one in the other.
My problem is that when the called EJB aborts with an exception, the caller does not receive the message of the exception and instead reports an internal error that is not helpful at all in diagnosing the problem. What happens seems to be this:
At the transport layer, a org.omg.CORBA.portable.ApplicationException is created,which already loses all detail information about the exception except its class.
Inside com.sun.jts.CosTransactions.TopCoordinator.get_txcontext(), the status of the transaction ass rolled back causes a org.omg.CosTransactions.Unavailable to be thrown, which gets wrapped and passed around a few times and eventually results into this error being displayed to the user:
org.omg.CORBA.INVALID_TRANSACTION: vmcid: 0x0 minor code: 0 completed: No
at com.sun.jts.CosTransactions.CurrentTransaction.sendingRequest(CurrentTransaction.java:807)
at com.sun.jts.CosTransactions.SenderReceiver.sending_request(SenderReceiver.java:139)
at com.sun.jts.pi.InterceptorImpl.send_request(InterceptorImpl.java:344)
at com.sun.corba.ee.impl.interceptors.InterceptorInvoker.invokeClientInterceptorStartingPoint(InterceptorInvoker.java:271)
at com.sun.corba.ee.impl.interceptors.PIHandlerImpl.invokeClientPIStartingPoint(PIHandlerImpl.java:348)
at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:284)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:184)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:186)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
at com.sun.corba.ee.impl.presentation.rmi.bcel.BCELStubBase.invoke(BCELStubBase.java:225)
Is there anything I can do here to preserve information about the actual cause of the problem?
The cause of the problem should be available in the server log of the domains hosting the EJB that had a problem.
It sounds like getting more info back from the other end may be difficult... I do not know which issue tracker would be the right one for the info lost when the ApplicationException is created/thrown.
A total hack would be to create a set of custom exception classes in the project that has the ejb that has failed. You would make them very fine grained to cover the likely causes of the problem and provide enough detail in their name to identify the actual location of the problem, too. Yucky... but that may be the only choice until an issue gets filed and the fix is distributed.
Is there anything I can do here to
preserve information about the actual
cause of the problem?
Unfortunately, no. The ORB does not use normal object serialization for system exceptions (i.e., org.omg.CORBA.*), which means that causes are lost. As #vkraemer said, you'll need to rely on server logs.
I finally got to the bottom of this: actually, Glassfish transmits exceptions through IIOP quite correctly and everything works as it should... unless you do something idiotic like this:
try{
ejb.getFoo();
}catch (Exception e){
// try again
ejb.getFoo();
}
Yeah, it was our own damn code that swallowed the exception and tried to call a transaction-requiring EJB method within a distributed transaction that's been rolled back due to the exception.