D
dbeavon
Guest
It would have been *really* nice if those new -catchStop 1 exceptions would auto-magically be marshalled back to the .Net openclients with a meaning message (just like the occasional AppErrors that escape out of an ABL session in PASOE.) There is so *much* impedance going on here. First of all the error condition (Progress.Lang.LockConflict) doesn't derive from normal error classes, or even implement the regular Progress.Lang.Error interface. So any error-handling I've already written (unwillingly-written logic that translates from CATCH statements to RETURN ERROR statements) is totally useless. Secondly, a lock conflict comes up so infrequently that NOBODY wants to write special logic for it. It should be handled in the most generic possible way - one that takes advantage of the automagic "S.E.H" functionality which is built into the framework. Thirdly our users on the .Net side get far too many indecipherable messages from our applications. They don't want to see another unusual message which simply says that a “4GL STOP condition” occurred. Even an ABL programmer doesn't really know what that means - and it might not even be a lock conflict in many cases. If the error is happening because of a lock conflict, then in the very least it should say as much, and it should also give the name of the database record (and possibly the user that owns it). I can understand that some of the work needed to improve things has to be done by the Progress team responsible for the .Net openclient. And that can take time. But in the meantime we are in a fairly awkward state of limbo, and we're forced into doing a ton of manual effort for ABL developers to watch for "LockConflict" .... and translate it ... so it can be consumed by our applications. As I said earlier, the manual effort will involve doubling-up all the generic error-handling that we've already written - so that we don't ignore another indecipherable set of generic errors (derived from the new Progress.Lang.Stop). As far as the openclient goes, in the very least it would be nice if Progress could give us a roadmap, and an ETA for the changes that are coming. Will the client only be available for OE 12? Will it be fully backwards-compatible with PASOE running on 11.7? Will the openclient for .Net match the functionality of the Java openclient? Will there be any breaking changes requiring us to do work on our side? By giving us some kind of a roadmap, it might help us determine if we really must invest in all the custom programming effort that is related to "LockConflict/Progress.Lang.Stop". I suppose that we can put lock-wait timeouts back to 30 minutes (the way they were in classic appserver) and that "solves" the problem to some extent. But now instead of an indecipherable message, the users get an experience where their applications become unresponsive for extremely long periods of time). I agree that it would be nice for others to chime in and have some opinion about this. But it might be that the people with the Java openclient don't care, because things are already working better for them on that side. The only people who care about this might be the .Net openclient customers (however many there are).
Continue reading...
Continue reading...