I catch RejectedExecutionException and handles it properly. But, I would like to know how should I catch and handle the case when the server/jvm crashes abruptly. Could anyone please help me out here ?
There i no way you can handle that situation, since the JVM itself crashes you can't expect any of your code to run properly during that time.
Related
I have a vb.net desktop application and I am using thread.Abort() there.
I am getting system.threading.threadabortexception error.
Below is the error messagebox i am getting but not everytime.
Unhandled exception has occured in your application. If you click
Continue.....
Thread was being aborted.
Please suggest how to avoid this errormessage.
Please suggest how to avoid this error message.
The best, and correct, way to avoid this is to not call Thread.Abort(). Thread.Abort() is really a bad idea in general. Instead, you should build your routines around the cooperative cancellation model built in the framework.
I use NSTask to run my helper application. On 99% one my customer systems this works fine, but two got back to me letting me know it doesn't. One of them was nice enough to let me look into the issue per remote desktop.
I tried a lot of different NSPipe/NSFileHandle combination for StandardOutput/StandardError to make sure the problem is not related filling up these buffers. Example 1 and 2. My guess is that it is not related because it works fine on so many systems and _dyld_start is too early on in the application lifecycle to fill up StandardOutput/StandardError.
Other notes about the problem:
Launching the helper app from the terminal works fine.
Attaching and detaching the gdb on the stuck process and after-worth it works fine and when it finished NSTask picks up work after -waitUntilExit.
Using fork(2) and execv(3) instead of NSTask is able to launch and run the helper fine.
The parent process is sandboxed but I think previous reports where non-sandboxed on Mac OS X 10.6/10.7.
Screenshot of the process Sample from Activity Monitor:
Any clues or debugging tips to figure out why the helper is stuck in _dyld_start are welcome!
Since nobody answered, I am throwing a few ideas. Maybe one of them is the answer – only guessing – but since clues and tips are welcome, you could take a look at:
the list of the loaded libraries in the crash dump (there may be a clue there)
any error that would happen in the child process (after the fork). However, I see why it could be difficult to get back any post-fork error.
If I recall correctly, NSTask calls posix_spawn(2). This may be a clue, since using fork(2) and execv(3) seems working, you could focus on the differences between NSTask and the non-blocking alternative. Clearly, something is happening at the very beginning that prevents the child from executing properly.
Are you sure it is stuck and not crashed? As far as the user could tell, your app your app wouldn't look like it crashed. Only the child process would crash.
As a last resort, you could try to look for any Mach exception occuring (if
any, that would mean an error, which you wouldn't be able to
recover anyway. But it would provide valuable clues nonetheless).
You can tell willing custommers to send you their sysdiagnose. To this goal, ask them to hit Command + Option + Control + . + Shift to wait a few minutes. Soon after, their finder should pop a window to reveal a file named: sysdiagnose_timestamp_.tar.gz. Kindly ask them to mail it to you. Mine is around 5 MB. More details on the sysdiagnose man page.
I have an Adobe Air mobile application that has a NetConnection. One on call to my AMF server it makes the call and everything returns fine. When I make a second call my app crashes.
Anyone one run into this?
you're going to need to get more info. Run it in debug mode and you should get a stack trace, variable values and the like.
Figured it out. My models in the client and on the server didn't match. Why AIR just crash and didn't give me an error is weird.
Maybe your server client is the cause of the error!
It may be the reason of automatic combine of the two amf calls by NetConnection.
So, your function on server side will be run twice.
Check your require or require_one on server side.
Is it possible to have some sort of global action/event that triggers in the event of a fatal error? I'd like to be able to have my program write an error file and/or perform other "last breath" (no idea what else to call it...) action if a fatal or unhandled exception occurs that would cause the program to close or crash. Is such a thing possible?
I'm programming in VB.NET v4 using VS2010, if that is important. Also, all users of my app will be authenticated as an administrator (if that matters?).
It depends on what kind of application you're writing, but these may help:
Application.ApplicationExit
Application.ThreadException
AppDomain.UnhandledException
Yes there is AppDomain.UnhandledException Event. And no you do not need any permissions to use it.
When I do the try/catch method in my vb.net project I will try the code I want and when it can't do it, i make a message box right after the catch method. The thing is that it will show the message box, and then another message from the program itself. Like for example, I have here a MySQLException, and when i click ok on the message box, it will show another one right after showing the exception itself. How would I be able to get rid of this so the user doesn't have to see this, and the program can continue.
Thanks,
kevin
It sounds like you're actually getting more than one exception. Have you checked the stack traces for both errors?
What I think is happening is that your first function is throwing the MySQLException and then returning nothing. You're then probably getting a NullReferenceException from whatever made the call to the database.
Your best bet is to not catch some many exceptions. Your data layer should be free of Try/Catch blocks unless you're trying to cater for something very specific. Your business layer should then catch any other non-general exceptions that occur specific to the functionality there. Finally, your application layer should be handling all of your general exceptions and reporting on them from there.
Try this. It should only display one message. Make sure your original message is coming from a statement after the Try.
Try
code
Catch ex as exception
call msgbox (ex.message)
end try