While debugging, I've always been able to see information about the exception once a catch block was entered even if my catch just looked like this:
catch
{
}
Since updating to Visual Studio 2017 though, I am only able to get exception information if I've actually declared a variable like so:
catch (Exception ex)
{
}
This is super annoying because there are a number of places where the exception is not declared (and normally does not need to be) but I do need to see what the exception is while debugging if there is one. How can I get the behavior back where it always shows me about the exception regardless of whether I've declared a variable for it or not?
In the locals window you should see a pseudo variable $exception that has the exception object for you to inspect. You can also add a watch expression for $exception in any of the watch windows.
Docs with more info and other pseudovariables is at: https://learn.microsoft.com/en-us/visualstudio/debugger/pseudovariables?view=vs-2017
Related
I'm trying to get some data from Application.Current.Properties storage. Unfortunately, any time I want to use this Dictionary, I see this error:
An exception of type 'System.AggregateException' occurred in mscorlib.ni.dll but was not handled in user code
Additional information: One or more errors occurred.
And in details I found this:
{"Error in line 1 position 206. Element 'http://schemas.microsoft.com/2003/10/Serialization/Arrays:Value' contains data of the 'http://schemas.microsoft.com/2003/10/Serialization/Arrays:ArrayOfstring' data contract. The deserializer has no knowledge of any type that maps to this contract. Add the type corresponding to 'ArrayOfstring' to the list of known types - for example, by using the KnownTypeAttribute attribute or by adding it to the list of known types passed to DataContractSerializer."}
It seems like I tried to save some non-string data to Application.Current.Properties. Unfortunately I can't run .Clear() method to erease all data, bacause I receive this error any time I'm trying to access this property.
What should I do to make it work?
Well, as its name suggests AggregateException, is just a container for one or more exceptions which may be thrown when using PLINQ or TPL.
As such exceptions may be thrown on different threads and may also occur concurrently, the system automatically catches and rethrows them within an AggregateException wrapper to ensure that they all get reported in one place. The exceptions themselves are exposed via the InnerExceptions property.
You can catch an AggregateException and check which exceptions it actually contains with code such as the following:
try
{
// perform some parallel operation
}
catch (AggregateException aex)
{
string messages = "";
foreach(Exception ex in aex.InnerExceptions)
{
messages += ex.Message + "\r\n";
}
MessageBox.Show(messages);
}
So I suggest you do this to see what is causing the problem
Please, remove your app from your device, Settings - Applications- Uninstall, this works for me. The Auth Object was crash in debug mode.Clean and Rebuild can be Helpfull to.
I'm currently working through a project that is using HP's Fortify SCA tool to catch security issues in the code base. I'm having a bit of issue determining the best approach to correctly handling JDBC resources.
The code I have at the minute looks like this;
try (Connection conn = new DatabaseService().getConnection();
PreparedStatement ps = conn.prepareStatement(query);) {
ps.setString(1, mString);
try (ResultSet rs = ps.executeQuery();) {
while (rs.next()) {
...Do logic...
}
} catch (SQLException e) {
e.printStackTrace();
}
} catch (SQLException e){
e.printStackTrace();
}
}
The problem is that Fortify will flag this code stating that if an exception were to happen in the nested try statement then the reference to conn and ps will be lost and they won't be properly closed. Is fortify correct to flag this or is it a false positive? From what I understand try-with-resource should always close their resource but perhaps this doesn't always happen when they're nested like this.
I've scoured other related questions and blogs around the internet but I haven't been able to get any definitive proof on this.
The most documented solution that's always safe in this situation is to not use try-with-resource and wrap each resource with a try-catch in both the catch and finally blocks of a broader try-catch statement. However, I'd rather avoid this because it's horribly verbose.
Thanks in advance!
Edit: So I realized I've left something out of the code when I was re-writing it into SO. The original catch blocks had a System.exit(1); statement in them (bad practice I know). That would mean that if an exception was thrown in the nested try-with-resource then Fortify would be correct to say the conn and ps would not be properly closed.
Thanks for the replies, without the System.exit(1); all resources in this situation will be closed properly and I've selected the answer indicating that.
Using try-with-resource is always supported on Java 7 and higher, no matter tooling is sitting on top of it.
So, if this code compiles (meaning you are on Java7+), you can safely ignore any warnings as they are indeed false positives. The auto-closing resource contract is guaranteed for JRE classes.
Now, if you decide to write you own resource that implements AutoCloseable then it's up to you to make sure that the close() method actually closes the resource =)
The Fortify Java translator may never have been updated with this Java 7+ construct. You should contact Fortify Technical Support and submit the test case. The analysis is incorrect.
Further, you should mark this and other identical findings "Not an Issue" and move on with your life.
This question already has answers here:
Am I right to ignore the compiler warning for lacking await for this async call?
(3 answers)
Closed 7 years ago.
Below is my code. Compiler gives warning because AddLog is not awaited. I do not want to await this call and want to continue executing next lines. I dont have any concern if the exception is consumed also. Is it fine to ignore the warning?
public async Task Add()
{
this.AddLog( "Add executing" );
// Logic to Add Customer
}
public async Task AddLog( string message )
{
// Write to DB
}
Assuming you truly want to call the AddLog method in a fire-and-forget way, then you have a few options.
If, by design, you want AddLog to always be invoked as a fire-and-forget method, then you could change the signature to not return a Task.
public async void AddLog( string message ) // change Task to void
{
// Write to DB
// WARNING: Make sure that exceptions are handled in here.
}
However, if you do this, you better make sure that exceptions are properly handled from within the AddLog method. If any exception goes unhandled, it will crash your process.
Another option is to change the way you invoke AddLog to clearly state your intent that you don't care about when the Task completes, or about any exceptions that may be raised. You can do this by defining an empty continuation (Well, almost empty. See my edit at the bottom of the post for why it's a good idea to read the Task.Exception property at the very least).
// see EDIT for why the Task.Exception property is read here.
this.AddLog("Add executing").ContinueWith(t => { var observed = t.Exception; });
With either option, unless you are awaiting on other code inside your Add method that you are not showing us, then there is no longer any point in defining your Add method as async. You can simply turn it into a regular synchronous method. Otherwise, you'll then get another warning telling you that This async method lacks 'await' operators and will run synchronously....
public void Add() // no need for "async Task"
{
// see EDIT for why the Task.Exception property is read here.
this.AddLog("Add executing").ContinueWith(t => { var observed = t.Exception; });
// Logic to Add Customer
}
In any case, I wouldn't simply ignore the warning. Much like sometimes we get the warning Use of unassigned local variable 'x' in cases where we know that our code is fine, we typically don't ignore the warning. Instead, we may explicitly initialize the variable to null just to make our intent clear, and make the warning go away. Similarly, you can make the warning go away by making your intentions more explicit to the compiler using one of the above options.
EDIT: Word of caution about unobserved exceptions
I should also mention that even with the ContinueWith option, you may have to be careful about unhandled exceptions that come from your AddLog method.
According to this article, the way unobserved exceptions from tasks are handled has changed between .NET 4.0 and .NET 4.5. So, if you are still running .NET 4.0, or if you forcing .NET 4.0 exception behavior via configuration, you run the risk that unhandled exceptions will crash your process whenever the task gets GC-collected and finalized.
To make sure that this is not a problem, you can adjust the continuation to explicitly observe the exception, if any is present. You don't actually need to do anything with it, you just need to read it. This is one way to do it safely:
this.AddLog("Add executing").ContinueWith(t => { var observed = t.Exception; });
I've updated my earlier examples above to use the safer version of the continuation.
I would make add() non async since it isn't...and then task.run on add log
Background:
In my Oracle database, I have plenty of database calls which can cause exceptions. I currently have exception handlers for all these, which call an error package. To cut a long story short, a raise_application_error is eventually raised, for expected errors, or a raise for unexpected errors, and this is sent back to the calling Java Groovy/Grails application layer.
So, for example, if a user enters an id and clicks search, I run a select query from the database. If the id doesn't exist, I have a NO_DATA_FOUND exception which performs a raise_application_error with a custom error message (i.e. "ID entered cannot be found.")
However, the application development team say they're struggling with this. They are trying to perform unit testing in Groovy and ideally want a variable returned. The SQL exceptions I am currently returning cause all tests to fail as it is an exception. Their code looks like this:
void nameOfProcedure() {
String result = storedProcedure.callDBProcedure(ConnectionType.MSSQL, val1, val2)
log.info "SQL Procedure query result value: "+ result
assertEquals("1", result)
}
They can add something like this above the test:
#Test (expected = SQLException.class)
But this means all returning SQLExceptions will pass, regardless of whether they are the right exceptions for the issue at hand.
Question:
What is the best solution to this issue? I'm being pressed to return variables from my exception blocks, rather than raise_application_errors - but I'm very reluctant to do this, as I've always been told this is simply terrible practice. Alternatively, they could make changes on their end, but are obviously reluctant to.
What's the next step? Should I be coding to return "expected" errors as variables, as opposed to exceptions? For example, if someone enters an ID that isn't found:
BEGIN
SELECT id
FROM table
WHERE id = entered_id
EXCEPTION
WHEN NO DATA FOUND THEN
RETURN 'ID cannot be found';
END
Or alternatively, should they be following a guide like this which advises using Hamcrest matchers to create their own custom exception property, which they can check against in their JUnit testing. What is best practice here?
You're right, it's terrible practice. It just 'wagging the dog'; they're being lazy to work good and wish you to spoil application design in order to please them.
Generally, unit test with exception returned should looks something like this:
try {
String result = callDBProcedure();
fail("Result instead of exception");}
catch (OracleSQLException e) {
assertEquals(e.errorCode, RAISE_APPLICATION_ERROR_CODE);}
catch (Throwable t) {
fail("Unexpected error");
}
They can upgrade this as they wish. For example, they can develop procedure 'call the SP and convert exception to anything they wish' and use it in their tests. But they should not affect application design outside testing. Never.
I'm working off of the following example to implement editing of a cell in my grid when the cell is clicked:
http://demos.telerik.com/aspnet-ajax/grid/examples/dataediting/editondblclick/defaultcs.aspx
I'd like it to work just like in the example, but based on a single-click. I can't get it to work as I keep getting the following error buried away in Telerik.Web.UI.WebResource:
0x800a139e - Microsoft JScript runtime error: Sys.WebForms.PageRequestManagerServerErrorException: The string was not recognized as a valid format.
If anyone can lend any assistance, I will you owe you my first-born, as I am pulling my hair out trying to get this to work.
Thank you
Initially, the error was here but it didn't seem essential:
protected void detailsGrid_ItemCreated(object sender, GridItemEventArgs e)
{
if (e.Item is GridDataItem && e.Item.IsInEditMode)
{
((e.Item as GridDataItem)["detailsGridMonthOneCol"].Controls[0] as RadNumericTextBox).Width = Unit.Pixel(50); // ArgumentOutOfRangeException - Specified argument was out of the range of valid values
}
}
detailsGridMonthOneCol is the name of the column I double-clicked. This didn't seem essential, so I commented it out and that's when I got the following error:
Unhandled exception at line 15, column 16485 in http://localhost:63919/Telerik.Web.UI.WebResource.axd?_TSM_HiddenField_=RadScriptManager1_TSM&compress=1&_TSM_CombinedScripts_=;;System.Web.Extensions,+Version=4.0.0.0,+Culture=neutral,+PublicKeyToken=31bf3856ad364e35:en-US:10a773fc-9022-49ec-acd6-8830962d8cbb:ea597d4b:b25378d2;Telerik.Web.UI,+Version=2012.2.815.40,+Culture=neutral,+PublicKeyToken=121fae78165ba3d4:en-US:bd12f06c-2391-4523-868e-0017245d9792:16e4e7cd:ed16cbdc:f7645509:24ee1bba:e330518b:1e771326:8e6f0d33:6a6d718d:58366029:4b09f651:a2c5be80:874f8ea2:c172ae1e:f46195d3:9cdfc6e7:2003d0b8:c8618e41:e4f8f289
0x800a139e - Microsoft JScript runtime error: Sys.WebForms.PageRequestManagerServerErrorException: The string was not recognized as a valid format.
The code is buried away but here's where the exception gets thrown:
var e=this._get_eventHandlerList().getHandler("endRequest"),b=false;if(e){var c=new Sys.WebForms.EndRequestEventArgs(a,f?f.dataItems:{},d);e(this,c);b=c.get_errorHandled()}if(a&&!b)throw a}
In your Script Manager add a handler to the OnAsyncPostBackError="myScriptManager_AsyncPostBackError" and in code behind just put one breakpoint on the open curly brace of the method.
protected void myScriptManager_AsyncPostBackError(object sender, AsyncPostBackErrorEventArgs e)
{ // breakpoint this line.
}
doing this, probaly, this breakpoint will be hit and you could debug your code, and inspect who was thwrowing the exception.
This can help, but, the only way to help you, in fact, is if you provide the full source code. I suggest you to create another project, isolate the code that you want to work, and publish this code on github, ftp, etc.
Please, post your code and i will help.
The code is not really buried away. Javascript is showing you this error. However. the error is happening on the server side (Sys.WebForms.PageRequestManagerServerErrorException)
Check the Event Viewer (start => Run => eventvwr) it will show you more details of the error.