Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Alex]

@NoFoodAfterMidnight: Another potential issue is that any exception that occurs within your code will look like it took place in vanilla code. That could make things very difficult to troubleshoot, especially for anyone who doesn't know about this aspect of your mod's implementation. It might be worth catching and re-throwing any error that occurs in your overriden API methods so you can add a message to the log about how your mod encountered an error.

Oh, that's a super good point, and, uh, that could really blindside me. Glad you brought it up, since I'm at least directly aware of it now.

[NoFoodAfterMidnight]

@NoFoodAfterMidnight: Another potential issue is that any exception that occurs within your code will look like it took place in vanilla code. That could make things very difficult to troubleshoot, especially for anyone who doesn't know about this aspect of your mod's implementation. It might be worth catching and re-throwing any error that occurs in your overriden API methods so you can add a message to the log about how your mod encountered an error.

That's a great point, I didn't think about that. I've taught myself java up until now, exceptions/error reporting in any language is pretty complex, so to make sure I do it right and not butcher the error/stack trace, how would you guys do it?

[Sundog]

Well, there's likely a more elegant solution, but what I had in mind was something like this:

Code: java

public class FleetFactoryV3 {
	public static CampaignFleetAPI createFleet(FleetParamsV3 params) {
		try {
			myObject.doModStuff();
			
			vanillaObject.doVanillaStuff();
		} catch (Exception e) {
			Global.getLogger(FleetFactoryV3.class).error("NoFoodAfterMidnight's difficulty mod encountered an error!");

			throw e;
		}
	}
}

This would ensure that the game crashes and logs the stack trace as normal, only preceded by a message identifying you as the appropriate point of contact and leaving a clue about the stack trace referring to your modified API instead of the vanilla one.
This approach would fail if you were to modify a field (member variable) in such a way that it caused an exception somewhere that isn't wrapped in a try block, so I would be extra careful to avoid that.

[Nick XR]

Another concern would be security.  I'm pretty sure janino is running in a Security Manager constrained manner, but if an API altering mod could include some hostile code that could do all sorts of naughty things if the user is running in Admin mode (which probably a small % of people are).  All it would take is for someone to take over a popular defunct mod and inject that, or to make their own mod and include bad bits.

Something like this:  https://thehackernews.com/2018/11/nodejs-event-stream-module.html
Although NPM is a dumpster fire when it comes to security so finding an exploit related to NPM is easy.

[Alex]

Bit of a necro, but: added plugins that allow replacing FleetFactoryV3.createFleet() and DModManager's various .addDMods() methods.