When I create a new project (web api) in Visual Studio 2019, I try running the project but I got the following error:
An unhandled exception occurred while processing the request.
SqlException: Invalid object name 'Books'.
Microsoft.Data.SqlClient.SqlCommand+<>c.b__169_0(Task result)
Did you check spelling in SqlDataReader? For me, I was misspelled. If the spelling is correct, any chance are you re-using the same name of an existing environmental variable for a different database on the same SQL Server? If the answer is yes it can be issue too.
When exceptions occur in a UIPath project I have an email that is sent out with the exception info included. There seems to be an issue though where I can only see where the error occured by looking at the selector information such as:
Cannot find the UI element corresponding to this selector:
<html app='chrome.exe' title='Microsoft Dynamics GP' />
<webctrl aaname='Add' idx='1'
parentid='a00000000000000008549000000030009000000000001000000000000' tag='DIV' />
This info and the stack trace or any other info is not really helpful for quickly finding the source of the problem. I have looked through the UIPath documentation and forum and found only the this question, which seemed to point to using the exception.Source to show the name of the activity where the error occurred. exception.Source only returns “UiPath.Core.Activities” though instead of "Type into Copy Job# 'INPUT'" in the following example:
This obviously causes a big problem with exception handling. How can I easily return the source with each exception?
When your selector fails, you will end up with a new object of type UiPath.Core.SelectorNotFoundException. However, until the team at UiPath decides to add the Display Name into the inner exception, there is little you can do in this particular case.
Take the following example - the first line shows the Inner Exception, and the second one in red is essentially just the exception being rethrown. Note that only the latter one contains the Display Name property.
The Source itself will usually be of type UiPath.Core.Activities, but since this is just the type's name, we don't have any link to the faulting object. Here's what you can do:
Add some details to your exception. You don't want to do this for each activity, but you could have certain blocks of try-catches (example: logging into the system consists of three individual activites, and they reside in one block).
Rethrow the exception. That way the Display Name will end up in the execution log file.
I rise DUP_VAL_ON_INDEX in SQL and I'd like to associate some custom error message with it.
Right now after executing the code
IF ___SOME_CONDITION___ THEN
RAISE DUP_VAL_ON_INDEX;
END IF
I see following message:
00001. 00000 - "unique constraint (%s.%s) violated"
How I can provide custom message to substitute these "%s"?
You wouldn't typically raise these pre-defined errors yourself. Instead, you would either let the database raise them (eg. you really have tried to insert a row that violates the unique constraint/index) or raise your own custom error (eg. raise_application_error()) and provide the necessary information there.
I've built an integration with Rally using the SOAP API so that when I target a bug in bugzilla, a user story is created and scheduled in the proper release. It also work in update, so if I just update the target the US will be associated to the specified release in Rally.
It has been working for a while, but now it seems not to work anymore.
I get the following error:
org.xml.sax.SAXException: Invalid element in com.rallydev.webservice.v1_28.domain.OperationResult - Object
at org.apache.axis.encoding.ser.BeanDeserializer.onStartChild(BeanDeserializer.java:258)
at org.apache.axis.encoding.DeserializationContext.startElement(DeserializationContext.java:1035)
at org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:165)
at org.apache.axis.message.MessageElement.publishToHandler(MessageElement.java:1141)
at org.apache.axis.message.RPCElement.deserialize(RPCElement.java:236)
at org.apache.axis.message.RPCElement.getParams(RPCElement.java:384)
at org.apache.axis.client.Call.invoke(Call.java:2467)
at org.apache.axis.client.Call.invoke(Call.java:2366)
at org.apache.axis.client.Call.invoke(Call.java:1812)
at com.rallydev.webservice.v1_28.service.RallyServiceSoapBindingStub.update(RallyServiceSoapBindingStub.java:1166)
I updated to the latest API, but not luck.
Stefano,
This is a known issue in Rally and we expect it will be corrected this Saturday (3Dec11). If you need to get the code running right away, you can catch the thrown exception by editing the generated code.
As long as the SAX exception is caught, it does not prevent updates from actually succeeding. A couple customers have been able to workaround the mismatched return value by wrapping the update code and/or calls to the Rally service in a try/catch block similar to an example here on a Task:
try {
OperationResult operationResult = rallyService.update(myTask);
} catch (Exception e) {
System.out.println("Rally SAX Exception encountered");
}
Sorry for the inconvenience.
Mark
Let's suppose I want to inform the application about what happened / returned the SQL server. Let's have this code block:
BEGIN TRY
-- Generate divide-by-zero error.
SELECT 1/0;
END TRY
BEGIN CATCH
SELECT
ERROR_NUMBER() AS ErrorNumber,
ERROR_SEVERITY() AS ErrorSeverity,
ERROR_STATE() as ErrorState,
ERROR_PROCEDURE() as ErrorProcedure,
ERROR_LINE() as ErrorLine,
ERROR_MESSAGE() as ErrorMessage;
END CATCH;
GO
and Let's have this code block:
SELECT 1/0;
My question is:
Both return the division by zero error. What I don't understand clearly is that why I should surround it with the try catch clausule when I got that error in both cases ?
Isn't it true that this error will be in both cases propagated to the client application ?
Yes, the only reason for a Try Catch, (as in ordinary code) is if you can "Handle" the error, i.e., you can correct for the error and successfully complete whatever function the procedure was tasked to do, or, if want to do something with the error before returning it to the client (like modify the message, or store it in an error log table or send someone an email, etc. (althought i'd prefer to do most of those things from the DAL layer )
Technically, however, the catch clause is not returning an error. it is just returning a resultset with error information. This is very different, as it will not cause an exception in client code. This is why your conclusion is correct, ou should just let the original error propagate directly back to the client code.
As you have written it, no error will be returned to the client. As in ordinary code, if you do not handle (correct for) the error in a catch clause, you should always rethrow it (in sql that means Raiserror function) in a catch clause. What you have done above, in general is bad, the client code may or may not have any capability to properly deal with
a completely different recordset (one with error info) from what it was expecting. Some calls (like Inserts updates or deletes) may not be expecting or looking for a returned recordset at all... Instead, if you want or need to do something with the error in the procedure before returning it to the client, use Raiserror() function
BEGIN TRY
-- Generate divide-by-zero error.
SELECT 1/0;
END TRY
BEGIN CATCH
-- Other code to do logging, whatever ...
Raiserror(ERROR_MESSAGE(), ERROR_NUMBER(), ERROR_STATE() )
END CATCH;
Both return the division by zero
error.
Yes, but using different return paths.
The difference is that in the first example, you are anticipating the error and dealing with it in some way. The error enters the application as a regular result - it is not propagated via the error handling mechanism. In fact, if the application doesn't look specifically as the shape of the result, then it may be unaware that an error has occurred.
In the second instance, the error will propagate to your application typically via an error reporting mechanism, such as an exception. This will abort the operation. How big an impact this has will depend upon the application's exception handling. Maybe it will abort just the current operation, or the entire app may fail, depending upon the app's design and tolerance to exceptions.
You choose what makes sense for your application. Can the app meaningfully handle the error - if so, propagate the error (2nd example), or is it best handled in the query (1st example), with errors being "smoothed over" by returning default results, such as an empty rowset.
Try Catch is not as useful when all you have in the try portion is a select. However if you have a transaction with multiple steps, the catch block is used to roll all the steps back and possibly to record details about what caused the problem in a log. But the most important part is the rollback to ensure data integrity.
If you are creating dynamic SQl within the Try block, it is also helpful to log the dynamic SQl variable that failed and any parameters passed in. This can help resolve some hard-to-catch, "we don't have any idea what the user actually did to cause the problem" errors.
No, by executing Select 1/0 in a TRY/CATCH block the select statement returns nothing and the select statement in the catch block displays the error details gracefully. The query completes successfully - no errors are thrown.
If you run Select 1/0 on it's own the query does not complete successfully - it bombs out with an error.
Using a catch block within SQL gives you the chance to do something about it there and then not just let the error bubble up to the application.
The only reason you see the error details is because you are selecting them. If there was no code within the Catch block you wouldn't see any error information.
Using the first method, you wont get the error from SQL Server directly
The second method may stop the execution of the statements that follow it
So it is better you catch it in advance