I am Using this Library For AndroidPdfViewer
https://github.com/barteksc/AndroidPdfViewer
E/PDFView: load pdf error
java.lang.NullPointerException
at com.github.barteksc.pdfviewer.util.Util.toByteArray(Util.java:36)
at com.github.barteksc.pdfviewer.source.InputStreamSource.createDocument(InputStreamSource.java:37)
at com.github.barteksc.pdfviewer.DecodingAsyncTask.doInBackground(DecodingAsyncTask.java:49)
at com.github.barteksc.pdfviewer.DecodingAsyncTask.doInBackground(DecodingAsyncTask.java:25)
at android.os.AsyncTask$2.call(AsyncTask.java:288)
at java.util.concurrent.FutureTask.run(FutureTask.java:237)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at java.lang.Thread.run(Thread.java:841)
Here I am Getting nullPointer Exception on This Line.
inputStream=new BufferedInputStream(urlConnection.getInputStream());
It seems that this is not a library error, because it's a NullPointer raising due to the null parameter. your PDFViwer is unable to open the file hence it's throwing null pointer exception. you can check you code for the cause. you should follow the best practices to prevent such situations.
Check the connection first, it should not be null. you can check with ? ternary operator as given below.
// InputStream in = conn.getInputStream();
// check for the null connection first, it's possible that connection could not be made before opening the InputStream.
InputStream in = (conn != null) ? conn.getInputStream() : null;
Related
I'm trying to check whether an address is available for connection in C++.
In python it's quite simple, I make a socket and call 'connect_ex' like so:
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind((host,port))
res = s.connect_ex((other_host,other_port))
if res == 0:
print("connection available")
Is there a C++ equivalent to this?
Python connect_ex is actually C/C++ connect. Both Python connect and connect_ex do essentially the same, i.e. connecting to the given peer. The only difference is that connect throws an exception if the connection fails while connect_ex simply returns an error.
From the documentation:
Like connect(address), but return an error indicator instead of raising an exception for errors returned by the C-level connect() call (other problems, such as “host not found,” can still raise exceptions). The error indicator is 0 if the operation succeeded, otherwise the value of the errno variable. This is useful to support, for example, asynchronous connects.
Since C/C++ don't raise an exception on connect, they are more like connect_ex in the first place. There is no need to have an extra function for what the original function is already doing.
Looking at the source code you will see that both connect and connect_ex essentially call internal_connect, either with raise=1 or raise=0. And internal_connect is doing C connect.
I don't find anything in Protocol Buffers documentation for exception handling in C++. In Javadoc it has clearly defined ones like InvalidProtocolBufferException, but not in C++.
Sometimes I ran my program and it crashes when it finds missing fields in what it thinks a valid message, then it simply stops and throws errors like this:
[libprotobuf FATAL google/protobuf/message_lite.cc:273] CHECK failed:
IsInitialized(): Can't serialize message of type "XXX" because it is
missing required fields: YY, ZZ
unknown file: Failure
C++ exception with description "CHECK failed: IsInitialized(): Can't
serialize message of type "XXX" because it is missing required fields:
YY, ZZ" thrown in the test body.
The source code of message_lite.cc all wrapped around with "GOOGLE_DCHECK" or "InitializationErrorMessage"...
My application does not allow exceptions like this to halt the program (not sure what the term is in C++ but basically no UncheckedExceptions), so I really need a way to catch these, log errors, and return gracefully, in case some messages got severely corrupted. Is there anyway doing that? Why do I see this post indicating some sort of google::protobuf::FatalException but I couldn't find documentations around it (only FatalException probably not enough also).
Thanks!
The failure you are seeing indicates that there is a bug in your program -- the program has requested to serialize a message without having filled in all the required fields first. Think of this like a segmentation fault. You shouldn't try to catch this exception -- you should instead fix your app so that the exception never happens in the first place.
Note that the check is a DCHECK, meaning it is only checked in debug builds. In your release builds (when NDEBUG is defined), this check will be skipped and the message will be written even though it is not valid. So, you don't have to worry about this crashing your application in production, only while debugging.
(Technically you could catch google::protobuf::FatalException, but the Protobuf code was not originally designed to be exception-safe. Originally, check failures would simply abort the program. It looks like FatalException was added recently, but since the code is not exception-safe, it's likely that you'll have memory leaks any time a FatalException is thrown. So, you probably should treat it like an abort().)
I solved that
my problem was same you.
if another thread change size of proto item while you do serialization then FatalException throw
then at first I copy that in another proto item then I do serialize that.
ProtoInput item; // it is global object
.
.
.
fstream output("myfile",
ios::out | ios::trunc | ios::binary);
ProtoInput in;
in.CopyFrom(item);
size_t size = in.ByteSizeLong();
void *buffer = malloc(size);
if (in.SerializeToArray(buffer, size) == true) {
output.write((char *) buffer, size);
}
output.close();
free(buffer);
I have the following code, attempting to allow the program to run at startup:
HKEY key;
if(RegOpenKey(HKEY_CURRENT_USER,LPCWSTR("Software\\Microsoft\\Windows\\CurrentVersion\\Run"),&key) != ERROR_SUCCESS) {
std::cout<<"Unable to open Reg key last error - "<<GetLastError()<<"\n";
system("pause");
}
Omitting the parts that aren't necessary. It prints that there was an error creating the registry key with the error code 18, which according to this page means that I'm encountering an error that returns ERROR_NO_MORE_FILES. Unfortunately the description says the same thing and I don't know what this means in the case of creating a registry key. I have tried running the program as an administrator, the key does not already exist either. Thanks.
If you read the documentation, it states:
Return value
"If the function succeeds, the return value is ERROR_SUCCESS.
If the function fails, the return value is a nonzero error code defined in Winerror.h. You can use the FormatMessage function with the FORMAT_MESSAGE_FROM_SYSTEM flag to get a generic description of the error."
It does not state to call GetLastError(). Also, this has nothing to do with C++.
Your error checking is wrong. Registry API functions return error codes. They don't use SetLastError. You have to use the error code returned by the function to diagnose errors.
The obvious error in your code is the cast to wide text. That does not change the fact that your string is actually 8 bit text. Use the L prefix.
L"Software\\Microsoft\\Windows\\CurrentVersion\\Run"
For what it is worth, you should use RegOpenKeyEx to open keys rather than RegOpenKey. And for creating keys use RegCreateKeyEx.
I had the same result (GetLastError() returned ERROR_NO_MORE_FILES) when trying to call RegCreateKeyEx() on a registry key where the running process had insufficient rights (in my case "HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\Application"). When starting the process with elevated privileges it succeeded.
So maybe there could be a connection between error code 18 and UAC.
In openssl, I can get the errorno for the certificate from using the code :
if(SSL_get_peer_certificate(ssl) != NULL){
if((error = SSL_get_verify_result(ssl)) != X509_V_OK){
std::cout << "error no = " << error << std::endl;
}
}
But if I try to get the error string from this error like this:
std::string temp = ERR_error_string(SSL_get_verify_result(ssl), NULL) ;
all i get is:
error:00000013:lib(0):func(0):reason(19)
Is there any way to get the exact reason here?
I have loaded the error strings using this code:
SSL_load_error_strings();
But still i dont get the exact reason. And if i try to use
std::string a = ERR_reason_error_string(19);, The program crashes. What am I doing wrong?
Please use the function X509_verify_cert_error_string to get errors related to Verification of Certificates in OpenSSL. ERR_error_string gives error strings for other SSL lib related errors not for the certificate verification failure specific errors.
As for the crash, there is no reason code mapping to the value 19. All SSL error reason codes start from 100. So, ERR_reason_error_string must be returning NULL which is causing your code to crash.
I'm trying to read the install path for an application, and I'm baffled at the behaviour I'm getting. First, here's the code that didn't work (formatted it a little so it doesn't take up a huge line):
LONG status = RegQueryValueEx(
hkRegistry,
"InstallPath",
0,
®Type, (LPBYTE)installPath,
®Size );
if (status == ERROR_SUCCESS) {
// Handle success.
}
I realized that it was failing on the call to RegQueryValueEx, so I decided to probe the return value by throwing it within an exception by adding:
else {
throw Exception( status );
}
But then... the code started to work and the call to RegQueryValueEx succeeded. I've been able to repeat this behaviour as long as I throw something within the else. If I comment out the body of the else, the error returns.
Edit: Okay, I tried calling MessageBox instead of an exception and I get the same behaviour. If I comment it out, it stops working again.
Is there a rational explanation for this?
It's possible that the buffer for installPath is too small compared to the value contained in regSize (which must be initialized to the size of the buffer).
If installPath is a stack-allocated value I suspect that it is overflown, causing the value of status to get overwritten.