The application gets exit unknowingly with out catching the exception. We have implemented try catch functionality in the Application. I couldn't catch the exception in App unhandled exception.
For example, we have sub menu screen in our application, while clicking on the sub menu content listing screen is displayed. But some times continuously working on sub menu screen, the application gets exit with out unknowingly.
Kindly suggest.
Sub menu page sample code:
I have two stack panel and each having same set of codes for navigating to other pages.
private void stk_searchworkorder_MouseLeftButtonUp(object sender, MouseButtonEventArgs e)
{
try
{
(Application.Current.RootVisual as PhoneApplicationFrame).Navigate(new Uri("/MMS/WOSearch.xaml?History=false", UriKind.RelativeOrAbsolute));
}
catch (System.Reflection.TargetException ex) { } catch (Exception ex)
{
MessageBox.Show("Unknown exception", app.glbExceptionTitle, MessageBoxButton.OK);
}
}
private void stk_searchworkorder_MouseEnter(object sender, MouseEventArgs e)
{
try
{
SolidColorBrush br = new SolidColorBrush(Color.FromArgb(255, 40, 40, 40));
stk_searchworkorder.Background = br;
}
catch (System.Reflection.TargetException ex) { }
catch (Exception ex)
{
MessageBox.Show("Unknown exception", app.glbExceptionTitle, MessageBoxButton.OK);
}
}
private void stk_searchworkorder_MouseLeave(object sender, MouseEventArgs e)
{
try
{
SolidColorBrush br = new SolidColorBrush(Color.FromArgb(255, 0, 0, 0));
stk_searchworkorder.Background = br;
}
catch (System.Reflection.TargetException ex) { }
catch (Exception ex)
{
MessageBox.Show("Unknown exception", app.glbExceptionTitle, MessageBoxButton.OK);
}
}
You are most likely running out of memory. The WP8 operating system WILL terminate your app, without your app being able to catch any exception, if your application's memory usage goes over its limit.
Limits are here
For troubleshooting, you can query your memory usage within your app using the DeviceExtendedProperties class. At the end of the day, you will want to make sure your app never goes over 150.
You application likely has a memory leak.
Look in your App.xaml.cs file. There is an Application_UnhandledException method. Make sure you do proper handling of exceptions in this method, and if you set e.Handled = true, it won't crash the application thereafter.
Note that this doesn't capture EVERY possible unhandled exception - for example, OutofMemoryException will still crash the app, but it does catch a lot of them.
Not sure if I'm missing something but wouldn't you just use NavigationService.Navigate instead of (Application.Current.RootVisual as PhoneApplicationFrame).Navigate?
Related
Why we need multiple "catch" blocks even though we can write one generic
exception?
Is that important to know all the exception types and their purposes to make a good piece of code?
I googled a lot but still have confusions in exception handling. Any good example?
Generic Exception:
try{
//some code
}
catch(Exception e){
//print e
}
//that's it.
Multiple catches
try{
//some code
}
catch(IOException e){
}
catch(SQLException e){
}
There are several advantages of using multiple exceptions:
General exceptions will not let you know the exact root cause of the issue especially if many steps/checks involved in a method implementation. Also, If the exception occurs due to various reasons, you need to throw the different types of exceptions from your caller method implementation.
Eg: You can throw custom exceptions.
Here is your service code:
public void Login(string username, string password)
{
if(string.IsNullOrWhiteSpace(username) || string.IsNullOrWhiteSpace(password))
{
throw InvalidUserNameException();
}
if(!IsInternetAvaialable())
{
throw NoInternetAvailableException()
}
else
{
//Implement though your login process and if need use various custom exceptions or throw the exception if occurs.
}
}
public class InvalidUserNameException : Exception
{
public InvalidUserNameException()
{
}
public InvalidUserNameException(string message)
: base(message)
{
}
public InvalidUserNameException(string message, Exception inner)
: base(message, inner)
{
}
}
Caller Method:
try {
...
} catch(InvalidUserNameException e) {
// Show Alert Message here
} catch(NoInternetAvaibleException e) {
// Show Alert Message with specific reason
}
catch(Exception e) {
// Other Generic Exception goes here
}
Reference:
https://learn.microsoft.com/en-us/dotnet/standard/exceptions/how-to-create-user-defined-exceptions
1. Why we need multiple "catch" blocks even though we can write one generic exception?
Sometimes you might need to specify what causes the problem.
For example,
try {
...
} catch(IOException e) {
// Print "Error: we cannot open your file"
} catch(SQLException e) {
// Print: "Error: we cannot connect to the database"
}
With different errors, users can understand what went wrong easily.
If we go with
try {
...
} catch(Exception e) {
// Print "Error: " + e.
}
It's harder for the users to figure out what went wrong.
Also, we can send the users to different pages accordingly to the error if we use multiple catch-es.
2.Is that important to know all the exception types and their purposes to make a good piece of code?
Personally, I would go with important exceptions such as IO, DB, etc. that can cause serious trouble. For others, I would catch with general exception.
I have a question , why does java keeps throwing that exception ! Is the problem with the stream ? because I handeled all IOExceptionS !
[[jio0yh.java:12: error: unreported exception IOException; must be
caught or declared to be thrown]]>>
That's the exception that I'm getting!
here is my code
import java.io.*;
public class jio0yh{
public static void main(String[]args){
FileInputStream OD=null;
try{
File f=new File("Binary.dat");
OD= new FileInputStream(f);
byte[]b=new byte[(int)f.length()];
OD.read(b);
for(int i=0;i<b.length;i++)
System.out.println(b[i]);
} catch(FileNotFoundException e){
System.out.println(e.getMessage());
} catch(IOException e){
System.out.println(e.getMessage());
OD.close();
}
}
}
The OD.close(); in your IOException catch block is also susceptible to throwing another IOException.
You should surround the final OD.close() in a finally block:
// ... Any previous try catch code
} finally {
if (OD != null) {
try {
OD.close();
} catch (IOException e) {
// ignore ... any significant errors should already have been
// reported via an IOException from the final flush.
}
}
}
Refer to the following for a more thorough explanation:
Java try/catch/finally best practices while acquiring/closing resources
I am preparing a client for WCF service.
I provoked an fault exception in some method on a service site. I mean:
throw new FaultException<sth>(new sth())
When I catch this exception in WPF appliction:
catch (FaultException<sth> ex)
{
// something
}
everything works very clearly.
My point is, that I made a reflection on the service interface.
var type = typeof (someServiceInterface);
type.GetMethods();
and I want to catch the FaultException, when I call the method service in this way
try
{
var singleMethod = //do sth to get method
var result = singleMethod.Invoke(proxy, parameters);
return result;
}
catch (FaultException<sth> ex)
{
//1
}
catch (Exception ex)
{
//2
}
But I catch an Exception in second catch, not in the first. The type of this Exception is "System.Reflection.TargetInvocationException". I am confused and I wonder what cause such kind of problem.
I was writing a method for TCPServer. I've written a code as below:
// thread run
protected void threadRun(){
// continue running. don't stop
while(true){
try{
try{
}
catch(Exception e1){
try{
} catch(Exception e2){}
finally{
// skip
continue;
}
}
}
catch(Exception e3){
}
}
}
Content is not important. There were codes to accept client etc, but I have removed them to make sure about that it is not about details. Anyway, when I try to compile this code, compiler says for that continue line:
Error: continue is not inside a loop
By thinking that maybe I know it wrong, I've written the complete same code in Java as seen below:
class test{
public static void main(String[] args){
while(true){
try{
try{
}
catch(Exception e1){
try{
} catch(Exception e2){}
finally{
continue;
}
}
}
catch(Exception e3){
}
}
}
}
As I expected, java compiler doesn't give any error message and compiles successfully. What exactly can the problem be?
Apparently, continue (and break) can't break out of a finally block. Compiling this:
void run() {
loop:
while (true) {
try {}
catch (Exception e) {}
finally {
continue loop;
}
}
}
will give you this (omitting the label gives the same error you got):
Error: cannot continue out of finally block
I haven't yet found a justification or explanation of this restriction (edit: see ratchet freak's comment below). However, I can't imagine it's a super-common use case. You probably want to look at other options.
Is there any language that supports something like the below construct, or is there a good way to achieve this using the ubiquitous try-catch-finally?
try
{
} catch(Exception1 e)
{ .... }
catch(Exception2 e)
{ .... }
catch-finally
{
//Perform action, such as logging
}
finally
{
//This always occurs but I only want to log when an exception occurs.
}
I understand this depends on the particular language, but is there some such support in Java, C#, C++, PHP etc?
Put a "global" try/catch in your main program or high-level method. This catches all exceptions that are not caught elsewhere.
try
{
// Main method, or higher level method call
}
catch (Exception ex)
{
// Log exception here
}
Then, in your subordinate try/catch clauses, just handle your exceptions in the usual way, and then rethrow. The rethrown exception will bubble up to your main try/catch and be logged.
try
{
// Do your thing
}
catch(SomeException ex)
{
// Handle exception here
// rethrow exception to logging handler
throw;
}
I don't think so as the behaviour you describe can be easily modelled as:
boolean success = false;
try {
...
success = true;
} catch (Exception_1 e) {
...
}
...
} catch (Exception_N e) {
...
} finally {
if (success) {
// your "finally"
} else {
// your "catch-finally"
}
}
You can easily accomplish that in C#. A simple way would be to save the exception in your catch blocks, then in your finally block, log if the exception object is not null.
Exception ex;
try
{
}
catch (ExceptionType1 type1)
{
ex = type1;
}
catch (ExceptionType2 type2)
{
ex = type2;
}
finally
{
if (ex != null)
{
//Log
}
}
Visual Basic has a construct that can be used for this. This isn't really "finally" in the sense of [almost] never failing to execute, but it'll support the case when you only want to log the exceptions that you're handling, and you have access to the exception object within the shared code. You've also got the flexibility of having the shared code execute before or after the individual exception type code.
Try
...
Catch ex As Exception When TypeOf(ex) Is Type1 OrElse TypeOf(ex) Is Type2
...
If TypeOf(ex) Is Type1 Then
...
ElseIf TypeOf(ex) Is Type2 Then
...
End If
End Try
Something like this, as long as the language has throw with no parameters to rethrow a caught exception:
try
{
} catch(Everything) {
try {
throw;
} catch (Exception1 e) {
....
} catch (Exception2 e) {
....
} finally {
//Perform action, such as logging
}
} finally {
//This always occurs but I only want to log when an exception occurs.
}
That's if you want to log whenever an exception occurs - if you only want to log the ones you actually catch, then don't put the "Perform action" in a finally block, just put it after the end of the inner try-catch.