try{
imgball = Image.createImage("/ball.jpg");
//imgpad = Image.createImage("/ball.jpg");
}
catch(Exception e)
{}
The above code works as it is. But when i open imgpad statement, it gives me error of uncaught NullPointerException ? What can be wrong ?
P.S. I am working in a different Thread. If that matters.
The NullPointerException (NPE) must be later in your code. Your catch block will catch any NPE during image load.
As mdma mentioned, the NullPointerException must be later because when the Image.createImage("/ball.jpg"); fails, it will throw an Exception that you catch. Since you catch it and then do nothing, the value of imgball will be unset (null).
Since you are working from a different Thread, it's possible that you are accessing the variable too soon, but I assume the above reason is more accurate because imgball will probably always fail to be created since you give it the absolute path.
Ok. It was my mistake. I'd like to make it clear here for others to know.
The mistake I made was actually from the main thread. I'd written following :
refcan = new ReflectCanvas(2);
d.setCurrent(refcan);
And I was loading images in the constructor ReflectCanvas(). So it could bear the speed upto one image but not for two :)
Related
I recently completed making an asynchronous version for all the functions in a pure C API, wrapped with N-API to work with JS/TS as a nodejs addon.
The last problem I had to fix was making sure that C POSIX-style errors (ie, returned integer codes) were transferred correctly to the JS at the end of a worker's execution (with the corresponding string, for which we have both an enum of exceptions, and a list of error messages).
When thrown with napi_throw_error (as I did for the synchronous version of all our calls), within the napi_async_complete_callback, these exceptions were never caught at the JS level (I suppose it was because it was within a different async context; I saw online people having a similar problem with ajax). Instead, I opted to just construct my errors as napi_value types, and return these via napi_reject_deferred. This seemed to have the desired effect, of being caught properly when doing a try { await My_NapiWrapper_XYZ() } catch (ex) { ... }.
So I don't really have a problem to fix, but I AM intrigued. These napi_throw_error thrown errors do probably go somewhere. Though I have no idea where. Where should one look to catch an error thrown with napi_throw_error from a napi_async_complete_callback ? Can you give a code example ?
No, they don't go anywhere. It is a bug that I just opened with them:
https://github.com/nodejs/node/issues/41377
There is a general problem with handling exceptions in asynchronous callbacks. Normally, they cannot be catched and should lead to program termination but Node's developers have decided to try to keep it running when they can.
Alright, this is probably the biggest program i have ever written. I use task in it once so that on first run it will search all available files and folders for certain things. Everything works...well, did work. Now when i start the program after adding a few more features in. It is throwing stack overflow errors on things that never had a problem before.
My first one was right in the begging it threw on a simple return of,
return System.Environment.GetFolderPath(Environment.SpecialFolder.CommonDocuments)
i changed it to just return
public string BaseUpdaterPath { get { return "C:\\Users\\Public\\Documents"; } }
and it started working again.
it got alittle further into the program untill it runs a check to see if a specific path exists.
if (File.Exists(pathINI))
pathini is defined earlier as
string pathINI = (BaseProductPath + "\\" + Name + ".ini");
and baseproduct is
public string BaseProductPath { get { return BaseUpdaterPath + "\\" + Name; } }
these are things that should not be breaking. My error is this
An unhandled exception of type 'System.StackOverflowException' occurred in mscorlib.dll
with more investigation turns into this
Source Evaluation of method System.Exception.get_Source requires calling method System.Reflection.RuntimeMethodInfo.CreateDelegate, which cannot be called in this context. string
I can only imagine this has something to do with threading and the initial search that I am doing if this is the programs first run time.
If i can provide anymore information that i may have overlooked in my details i would be happy to provide it. I have not seen errors like this before that don't really give you much to go off of.
I may just end up throwing up a splash screen during that initial search if it's going to keep causing problems like this and have the rest of the program wait on that task.
UPDATE
I just stepped through my program starting at different steps and i was able to get past that check it kept kicking it out at. Then i got to a different if(foo == bar) and visual studio did this strange thing where it popped up a little loading window and said evaluating BAR then killed the program with
has exited with code -2147023895 (0x800703e9).
wtf is going on lmao
Another update incase anyone runs into this. I have a product preselected when i started up the programming, i wrote checks in to accommodate this however....it blocked me from being able to see what is really happening.
I disabled some code and let the thing run and after a while i found this little bastard popping up on the console
Exception thrown: 'System.IO.PathTooLongException' in mscorlib.dll
Exception thrown: 'System.IO.PathTooLongException' in mscorlib.dll
Exception thrown: 'System.IO.PathTooLongException' in mscorlib.dll
Exception thrown: 'System.IO.PathTooLongException' in mscorlib.dll
now i gotta track that down to wherever the hell it's throwing 5000 times and i should be good to go.
Update again if anyone cares.
I found out that even i caught and threw the exception away it was still getting stackoverflow in windows.old because they have tons of folders and files and i was running out of memory. My solution at this point is during the recursive file check to just discard anyfolder in windows.old. Cant think of a better way.
THE EPIC CONCLUSION...I AM A DUMBASS
i was having two properties check eachother
public bool IsInstalled { get
{
if (DefaultInstalledpath != null || DefaultInstalledpath != "Not Installed")
{
return true;
}
else
{
return false;
}
}
public string DefaultInstalledpath
{
get
{
else if(!File.Exists(pathTXT) && IsInstalled == true)
{
return "Discovering! Please Wait...";
}
.........
i don't wanna talk about the rabbit hole i just fell down
For diagnostic purposes I sometimes need to store the call stack that lead to a given state transition (such as granting a lock, committing a transaction, etc.) so that when something goes wrong later I can find out who originally triggered the state transition.
Currently, the only way I am aware of to retrieve the call stack looks like the following code snippet, which I consider terribly ugly:
StackTraceElement[] cause;
try {
throw new Exception();
} catch (Exception e) {
cause = e.getStackTrace();
}
Does somebody know of a better way to accomplish this?
I think you can get the same thing with:
StackTraceElement[] cause = Thread.currentThread().getStackTrace();
Well, you can improve it slightly by not actually throwing the exception.
Exception ex = new Exception();
ex.fillInStackTrace();
StackTraceElement[] cause = ex.getStackTrace();
Actually, I just checked: the constructor calls fillInStackTrace() already. So you can simplify it to:
StackTraceElement[] cause = new Exception().getStackTrace();
This is actually what Thread.getStackTrace() does if it's called on the current thread, so you might prefer using it instead.
If you want it as a String and use Apache Commons:
org.apache.commons.lang.exception.ExceptionUtils.getFullStackTrace(new Throwable())
There's a new option since JDK 9: StackWalker
It isn't as expensive as Thread.currentThread().getStackTrace().
see also How Expensive is Thread.getStackTrace()?
I implemented a custom AbstractJavaSamplerClient for JMeter, and the core runTest is like:
SampleResult results = new SampleResult();
results.sampleStart();
client.request("connector.ninjaHandler.savemove", opMsg, this);
while(optcode == null){
try {
Thread.sleep(10);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
results.sampleEnd();
results.setSuccessful(optcode);
However, I found Thread.sleep() will cause such exception:
Uncaught Exception java.lang.IllegalStateException: Timer already cancelled.. See log file for details.
I googled around and people say thread.sleep will cause the timer failed. However, I cannot avoid it since I'm testing a web-socket server, which means I need to wait the server response back...(It runs OK if I delete the thread.sleep between sample start/end)
However, the sample test org.apache.jmeter.protocol.java.test.SleepTest works well, which use the thread.sleep.
Any suggestions?
It is quite ridiculous since I found the problem comes from the library that I use...
After fix the patch from here, it works!
I am writing a program to read all files from an array.
Suppose in between if any file is corrupt or any reason it will stop the execution in between and throw an exception
I want to let the code running till end and at last it logged the error files instead of throwing exception?
try{
doSomethingThatMayRaiseAndException();
}
catch (Exception e){
NotifyTheUserThatSomethingBadJustHappened();
}
Exception here is the base class for exceptions, you may need to use a more specific one if you want to provide the user with details. But right now, what you need to learn is how to deal with exceptions. You can use the link provided by Oded, it is a good start. Then note what is the raised exception you need to handle, and handle it.