Did something recently change with the level of detail that the exception handlers give you for database exceptions? I have logic where I do different actions depending on the exception message, recently I noticed everything is just getting logged as "Error executing query". Then I have to go into service center to see the actual message. Maybe I'm going crazy but I swear this used to not be the case and it would at least give me something like foreign key restraint. I can go into service center and see this: "Error executing query. The UPDATE statement conflicted with the FOREIGN KEY constraint"But I programmatically want to do different things depending on the error message rather than go and manually check service center. Any ideas?
Hello,
This has to be handled programmatically, as you mentioned, since this is related to exception handling.
In this example, I used an action and added an exception handler of type AllExceptions, meaning it catches the highest-level exceptions rather than a specific one. Whenever this exception is triggered, I assign the response attribute IsSuccess to False.
Based on this response, I wrapped the action inside another wrapper action and used the IsSuccess value as a reference. For example:
This makes things much clearer when checking the logs in Service Center, since you can immediately understand the exact issue based on your custom message.
You can also check these references:
Appreciate your response I more was hoping that the database exception could give me something useful to then make decisions off of in the code. I already am doing where I make it fail based off the exception handler being hit and make my own message for the user, but it would be nice for me to know did this fail because of a foreign key error vs was there a collision etc. I'll just add more validation to avoid hitting their exception handler for the database because it really doesn't tell me almost anything to then make decisions off besides that it failed.
Specifically I was creating records for what errored and then depending on why it errored I could try and fix it through code, but the database exception won't tell me anything about why it failed so I can't do that self healing approach for the record. Just means I need more validation than I do now since I found outsystems did make this change to expose more generic errors when it comes to the database.
Oh, unfortunately, I agree with you @Spencer Buhler
Messages should be more detailed so that developers can quickly address the issue.
You're not imagining it. In newer OutSystems versions, database exceptions are often wrapped and exposed as generic messages like "Error executing query" in exception handlers, while the detailed database error is only available in Service Center logs.
Relying on exception message text for business logic is generally not recommended, since messages can change between versions and database providers. A better approach is to perform validations before the database operation or handle specific scenarios through business rules rather than parsing exception messages.
If you need the detailed database error programmatically, check whether it's available through the exception object in your OutSystems version, but in many cases the full DB message is only logged in Service Center.