My download may fail but the incomplete file is still in FileStorage how do i delete the file if the download fails.
The generic error handling code for errors is still invoked in the network manager so you can still get an event on that. In your init(Object) method do this:
addNetworkErrorListener(err -> {
// prevent the event from propagating
err.consume();
if(err.getError() != null) {
Log.e(err.getError());
}
Log.sendLogAsync();
Dialog.show("Connection Error", "There was a networking error in the connection to " + err.getConnectionRequest().getUrl(), "OK", null);
});
Notice that this code is there by default for new projects https://www.codenameone.com/blog/new-default-code.html
Another approach would be:
if(!Util.downloadUrlToFile(url, fileName, false)) {
// error in download
}
Notice that this is a blocking method so you can wrap it in a callSerially if you don't want that.
Related
According to this link, if the source has a problem when opening and throws an exception and it is also in try parentheses, JVM closes it. My question is how to inform the user now that this source is closed and we encountered a problem when opening this resource? In other words, how can this exception be handled?
Seems trivial. Usually, java code is running in some sort of 'no user interaction' environment (servers and the like). The right move is to let the exception bubble up - you want the daily job that is halfway through reading through the database to open the related file to then send the logs to long term storage or whatever it is to completely abort and write a note in the log file. Usually for jobs like that, there's some atomary functionality (in this case, perhaps each such file is independent of the others, and its okay to leave the 'broken' one in place for now until a server admin can look at it whilst continuing to process the remainder - in that case, the 'do the backup rotation thing on THIS file' is the atomary functionality): Catch all exceptions and write code that does what you want when the job fails. For example, my servers can send notifications straight to admin phones (via telegram or pushover, or using slack API, and there are many services that automate this for you too), if it's important, you'd write that in your catch block.
For code that is directly 'triggered' by a user, let's say a 'save file' function, then it's not so much 'the resource is now closed' - resources are not long lived (they cannot be - not if you use try-with-resources). They were either never open in the first place (you attempt to save a file to a dir that doesn't exist - the act of trying to make the new OutputStream already failed, it was never open to begin with), or, perhaps it did open, but it was to a USB stick and the user pulled it out halfway through saving. The resource is just closed, effectively, whether in java you .close() it or not - the entire stick is gone!!
The only thing the 'safe close' aspect of try-with-resources did for you is ensure that your Java Process isn't wasting a file handle.
You handle it the same way you handle pretty much any 'unrecoverable' (you can't write software that hypnotises the user into sticking that USB stick back into the machine, obviously - it is not recoverable as a consequence, like most exceptions) problem: You toss up a dialog box that explains the situation.
try (OutputStream out = Files.newOutputStream(saveGameFile)) {
boardState.save(out);
} catch (IOException e) {
// show dialog here
}
Even when using a try-with-resources, the catch clause still works.
private static void printFile() throws MyCustomException {
try(FileInputStream input = new FileInputStream("file.txt")) {
int data = input.read();
while(data != -1){
System.out.print((char) data);
data = input.read();
}
} catch (IOException e) {
throw new MyCustomException("There was an error while opening the resource", e);
}
}
I'm making an URL shortener with the Javalin framework and have this endpoint set up:
app.routes(()->{
path("",()->{
get("/:id", ctx->{
//do stuff
ctx.redirect("somewhere.com");
});
});
});
Problem is when I need to serve a javascript file to load into my html files. It tries to load from http://localhost:7000/qrcode.min.js but ends up going to the endpoint mentioned above. From what I read in the documentation this is normal behaviour, Javalin first runs the endpoint handler and then (if it doesn't find an endpoint) runs the file handler.
So how can I fix this? should I define a GET request at "/qrcode.min.js"?, I dont think the javalin context handler has a function that lets me return a .js file.
As Matt already suggested in a comment, it would be way cleaner if you'd prefix either path. That way, you could have /r/:id (or /u/:id with "u" for "URL") and the static files would not get in your way, or you could prefix your static files with e.g. /static/, or even just /s/ for brevity, and your shortened URLs would not get in your way.
If you, however, prefer to stick with your current scheme, you can simply filter out JavaScript files (or any other non-id request) in the handler and instead provide the file (however, if you previously had auto-generated ETags, you'd lose caching if you don't want to handle that yourself).
The latter solution would look like so:
app.routes (() -> {
path ("", () -> {
get ("/:id", ctx -> {
String id = ctx.pathParam ("id");
if (id.endsWith (".js")) {
String resourcePath = "your/classpath/resources/folder/" + id;
try {
InputStream resultStream = Thread.currentThread ()
.getContextClassLoader ()
.getResourceAsStream (resourcePath);
if (resultStream == null)
throw new NullPointerException ("Script not found");
ctx.contentType ("application/javascript");
ctx.result (resultStream);
} catch (NullPointerException e) { // script does not exist
e.printStackTrace (); // for development only!
ctx.status (404);
}
return;
}
// do stuff
ctx.redirect ("somewhere.com");
});
});
});
Depending on your preference, you can also handle the resultStream == null case where my code is currently throwing an NPE to be caught by the outer try/catch and omit the try/catch completely.
Setting the Content-Type is essential so that the browser knows that you're actually responding with JavaScript code. Also, I'm typically using Thread.currentThread ().getContextClassLoader () because we'd want the resource to be resolved based upon the current HTTP handler thread, which could, in theory, have a different class path/class loader than the class we're currently in.
Please note that, as stated above, this will not support client-side caching as the handler simply ignores all ETag headers sent with the request* and instead respond with the complete file which, with many requests in a short amount of time and large scripts, will certainly put way more stress on your disks and CPUs.
Thus, I'd actually recommend to prefix the static files route and let Javalin/Jetty handle all the caching and files magic.
* Actually, the header sent by the client is If-None-Match most of the time. The server would respond with an ETag to allow for caching in the browser.
I am writing a plugin which takes a message from discord and sends it to a minecraft server.
Minecraft clients have a hard time rendering emojis. Therefore I opted to use https://github.com/kcthota/emoji4j to convert all emojis into their shortcodes (example: 😃 -> :smile: ..or similar)
The problem:
When calling the static method shortCodify it never returns. Almost as if it kills the code where it is and never continues. No errors in console.
It almost seems as though calling the method kills it right there. Step 1 is never printed.
It is able to run through this multiple times (every time I send a discord message). It has not killed the process completely.
I have tried:
Adding the debug prints all over the place to try to track down the issue.
PS: don't hate me for mixing logger.info and system println, I am removing all of this later xD
Console output
13:35:48 [INFO] [Core] Emoji manager exists.
13:35:48 [INFO] [Core] Attempting shortcodify (contains 1738 emojis)
13:35:48 [INFO] DEBUG: EventChat.java step 0
Yes.... it stops there!
Code snippets:
My code / EventChat.java
Note: msg is a String
The if statement (of which you see the else) just checks that the emoji data was loaded, because I ran the config loading in a separate thread. Knowing it is able to get to here and prints that the data exists, this is not the problem.
...
} else {
logger.info("Emoji manager exists.");
try {
logger.info("Attempting shortcodify (contains " + EmojiManager.data().size() + " emojis)");
System.out.println("DEBUG: EventChat.java step 0");
msg = EmojiUtils.shortCodify(msg);
logger.info("new message: " + msg);
} catch (Exception e) {
logger.info("Catching exception");
e.printStackTrace();
}
}
logger.info("Emoji processed.");
Emoji4j / EmojiUtils.java
public static String shortCodify(String text) {
System.out.println("DEBUG: EmojiUtils.java step 1");
String emojifiedText = emojify(text);
System.out.println("DEBUG: EmojiUtils.java step 2");
for (Emoji emoji : EmojiManager.data()) {
StringBuilder shortCodeBuilder = new StringBuilder();
shortCodeBuilder.append(":").append(emoji.getAliases().get(0)).append(":");
emojifiedText = emojifiedText.replace(emoji.getEmoji(), shortCodeBuilder.toString());
System.out.println("DEBUG: EmojiUtils.java step 2.loop");
}
System.out.println("DEBUG: EmojiUtils.java step 3");
return emojifiedText;
}
I found the answer after what seems to be wayyy too long. (yes, 2 months lol)
NOTE: this only applies to anyone using JDA with emoji4j
JDA catches all Throwables by default and attempts to log it to the console but fails due to bungeecord not using the same logger (or something similar, I don't really know why).
I wasn't too stupid, as I tried catching all exceptions and logging them. BUT it was throwing a throwable instead of an exception.... for whatever reason...
So, long story short, I was catching excpetions and JDA was catching the Throwable that indicated the missing dependency and making the error vanish instead of printing to console.
Fix
try {
} catch (Throwable t) {
// error is now caught and can be logged using bungee's logger
}
I'm trying to append a text to a file using the URI which i receive from an intent. When I pick the file directly from the storage, everything works perfectly fine. Nevertheless, the problem occurs when I pick the file from categorized selectors like Pictures, Videos, Musics and etc... It throws an IllegalArgumentException and says that the file is read-only.
private fun alterDocument(uri: Uri) {
try {
val subject = subjectField.editText!!.text.toString()
val message = messageField.editText!!.text.toString()
contentResolver.openFileDescriptor(uri, "wa")?.use { it ->
// use{} lets the document provider know you're done by automatically closing the stream
FileOutputStream(it.fileDescriptor).use {
it.write("\n".toByteArray())
it.write(
generateJSON(subject, message).toByteArray()
)
}
}
} catch (e: FileNotFoundException) {
e.printStackTrace()
} catch (e: IOException) {
e.printStackTrace()
}
}
Does anyone knows any way to solve this problem? Thanks in advance.
A DocumentsProvider does not have to grant read-write access to its content. In particular, MediaDocumentsProvider does not.
Unfortunately, we do not have a way to limit the user to read-write content. So, you are going to need to gracefully handle this error and suggest to the user that they pick from a different documents provider.
Or, to detect the problem more positively, you would need to check the document's flags to see if FLAG_SUPPORTS_WRITE is among them.
I blogged a bit more about this situation.
Having a problem with Azure's sdk v10, when I'm uploading files the code carries on while the upload does its thing, but I'd really like to hold until the upload finishes.
I saw c# has an 'await' function, is there a Java way to handle this?
try{
AsynchronousFileChannel fileChannel = AsynchronousFileChannel.open(file.toPath());
TransferManager.uploadFileToBlockBlob(fileChannel, blob, 8*1024*1024, null, null)
.subscribe( azureResponse -> {
logger.info("Status code: " + azureResponse.response().statusCode());
if( azureResponse.response().statusCode() != 201){
logger.error("upload failed - " + azureResponse.response().body());
// throw exception
}
});
} catch( Exception e ) {
// handle the exception
}
I am not familiar with azure in particular but perhaps you can write a while loop that blocks thread executing until the upload process has finished. Something as simple as this should do the trick provided you have a separate boolean method that returns true when the file has finished uploading:
while(!hasFileUploaded())
{
// do nothing here
}
I am sorry if this answer seems a bit generic but without further knowledge about how and where the file is being uploaded I can't tell you exactly how to validate the upload process.