microsoft
Usage of ASSERTERROR ERROR('')
This page mentions that the usage of ASSERTERROR is a "critical error"
My understanding is that this means usages of ASSERTERROR outside of test Codeunits means that an extension cannot be submitted to AppSource
My code makes use of the following pattern
ASSERTERROR ERROR(''); // Silently rollback
// Insert some records eg to a log table
COMMIT
ERROR('halt execution with error message');
The effect of this is to silently rollback and continue execution, this allows insert of some records that are persisted despite the error. Finally we halt execution.
My suggestion would be to include a ROLLBACK function (as suggested here ) which would avoid the need to use ASSERTERROR ERROR('')
(This is assuming that my understanding of the linked documentation is correct)
We usually do similar stuff by invoking a background session via STARTSESSION() that performs the logging. If the main routine fails this will not roll back the data we wrote in those other session(s).
That should be okay in terms of guidelines.
That said, I do favor more transaction control in AL. So thumbs up for ROLLBACK.
The use of AssertError Error will not be supported in the non-test code. There are currently no plans to add the Rollback function but we will use this issue for tracking purposes and provide an update once we have some concrete plans.
Is the code ASSERTERROR ERROR('') discouraged? Or is the restriction due to other potential uses of ASSERTERROR ?
Assuming that there is nothing inherently problematic with silently rolling back and continuing execution. How about providing a wrapper for this in Codeunit 1 Application Management ie a public function SilentRollback which just calls this line of code? Rather than adding into the language functions.
+1, we use the same pattern today. One example is that it has allowed us to build rich custom XML error responses from SOAP webservices instead of relying on the native errors that would otherwise be returned when using ERROR to halt execution in a webservice session.
There's also another problem with the lack of ASSERTERROR: If you are building a framework where you want to catch any errors thrown inside a specific subroutine you cannot use TryFunction if transactions are required inside. The only other approach left I can imagine would be to wrap the entire subroutine inside IF CODEUNIT.RUN THEN but that forces you to pass all parameters via a single record along with the fact that OnRun trigger code isn't really guiding people towards clean code. Example of why this feels wrong: If I have 3 JSON documents (JsonObjects) that I want to pass to any event subscribers without allowing them to halt my overall execution, I would have to create a parameter record table with 3 BLOB fields and add the overhead of serializing the documents into each BLOB, wrap the publisher inside a codeunit OnRun trigger that deserializes the BLOBs and fires the publisher.
Overall I fully agree that this usage of ASSERTERROR is a hack so the ideal would be proper replacements, ie. something like ROLLBACK or even better a new TryFunction variant intended for transactions that enforces rollback but doesn't halt execution.
