Is it possible in Drools to throw an exception or should I return a String and when I get the response should I verify the String I received?
Example:
package droolsvalidation.droolsvalidation;
import drools.validation.Code;
rule "MyRule"
when
c: Code(code==null)
then
throw Exception
end
How can I do that if it's possible or how can I handle it?
And it would be great if you can show an example of how can I catch that Exception.
It is possible, yes, but I don't know if it is recommended. In any case, you can handle exceptions thrown during the execution of a KieBase by registering a ConsequenceExceptionHandler to it.
This answer explains the mentioned approach.
Hope it helps,
Related
Running the code below both in VSCode and in Visual Studio is reported as failed although the exception is swallowed :(
Why it works this way? How can I make NUnit forget about the thrown exception?
[Test]
public void TestExceptionReporting() {
try {
Assert.False(true);
} catch(AssertionException e) {
Log.Debug($">>> {e.ToString()}");
}
}
Why does it work that way...
Because NUnit processes and records the error internally before you can catch the exception. The exception is propogated after processing solely as a way to terminte the test. For that reason, it is no longer a good idea to catch NUnit's own exceptions in a test.
How can you make NUnit forget about the test failure?
This is an xy question. Please explain why you want NUnit to notice a failure and then forget it. There are lots of ways to make NUnit take note of a condition without failing, but to answer folks need to know what you are actually trying to do.
You could either edit this question (and I can edit my answer) or ask a new question about what you really want to do.
The most popular desicion for handling exceptions in rest service and return the error message to client - as i understand - is to catch WebApplicationException or MappableContainerException. But they are extending RuntimeExceprion (I don't understand why). As I know we should avoid handling RuntimeExceptions.
I need to handle such exceptions as "The entity with such name already exsists". I'm sure it is not a runtime exception.
Any other ways? I'm researching now Wrappers. May be you could excplain me the best way to solve my problem?
The way that I handle this is to have my own exception hierarchy, and to build a separate ExceptionMapper which handles this hierarchy. That allows me to pass back whatever information I need to (in my case a JSON-formatted response) in a standardized way.
I would still have an ExceptionMapper for WebApplicationException, otherwise the end user might receive some nasty looking responses. And if you want to be extra-safe then you can also put one in for Exception that picks up anything else you might have missed (the exceptions go to the most specific exception mapper for them, so putting one in for Exception doesn't affect them).
My Entity Framework will always targeting SQL Server.
So, in my program. What type of exception shall I catch?
DataException or SqlException ?
and in DAL, is it good to throw the exception again after logging?
I would suggest multiple catch and log both.
In live environment its not recommended to throw error to client system, however you always need to throw the error.
So its your call how to do it.
If its live show a beautiful error to client that something went wrong and we are looking.
I know that when there is an unhandled Exception in asmx that it generates a soapFault and returns it to the client. What I want to know is if there is a way to return a soapFault without throwing an exception. Throwing an exception is an expensive operation and I would like to avoid it if I can.
AFAIK there is no such option (short from building the complete XML/SOAP message yourself that is)... with WCF this could be slightly easier IMO
You can throw a SoapException and can customize it rather thoroughly:
http://support.microsoft.com/kb/833379/en-us
http://msdn.microsoft.com/en-us/library/aa480514.aspx
Is it advisable to have business logic in a finally block?
I have to send an email notification when a job is over (whether successful or not). Can I place the email logic in finally block?
The main danger I can think of is that the finally block has the ability to silently swallow exceptions and return values from the try block itself.
For example,
try {
doSomethingFancy();
} finally {
sendEmail();
}
If doSomethingFancy throws an exception, you will attempt to send an email. If somehow sending an email fails, sendEmail could throw an exception. This exception will "override" the original thrown one, and you'll never see it. It'll just vanish.
You could code around this defensively with more try / catch blocks, but just be aware...
Ideally you should have your business logic in Try block and Finally block should contain any cleanup task or any thing that must happen irrespective of success or failure of try block . You also need to make sure that the code in finally block does not cause any exception otherwise as Steven mentioned, the original exception will be lost if any.
You could do that in catch block in case if you intend to send error condition to designated email id. finally block is generally used for graceful-release of the resources mostly. I do not recommend sending email or performing any business rules within the finally block.
In my mind,
try {
doSomethingFancy();
catch(Exception ex) {
logError(ex);
}
sendMail();
Is the perfect pattern for this. Finally block should only be used to clean the mess the code in the try block could have left behind.