3
 Followers
17
 Likes

Meaningful Error Logs

Service Center
On our radar
A more meaningful error log that is easier to understand when an exception occurs. Specially when its database related.
Created on 14 Nov 2013
Comments (19)
Merged this idea with 'Delete rule: User friendly error message' (created on 02 Jul 2018 11:45:52 by Kilian Croese)

I would like an extra option to maintain a custom, user friendly error message with a delete rule.


For example, I have a Location entity and an Appointment entity. Appointment has a reference (LocationId) to the Location entity. On this reference the Delete Rule is set to Protect. So far so good. Now when a user tries to remove a Location object that is already been references by an appointment, a user is presented with an error message like this:


The DELETE statement conflicted with the REFERENCE constraint "OSFRK_OSUSR_8CA_APPOINTMENT_OSUSR_8CA_LOCATION_LOCATIONID". The conflict occurred in database "OSDEV1", table "dbo.OSUSR_8CA_APPOINTMENT", column 'LOCATIONID'. The statement has been terminated.


I think it would be a lot more user friendly if I could maintain an error message, like the following:

This location cannot be removed, since it is still being used.


I don't think a user is interested in all the table and database information.

You could of course check these conditions before actually deleting the object, but that kind of defeats the whole purpose of the Delete Rule.




This comment was:
- originally posted on idea 'Delete rule: User friendly error message' (idea created on 02 Jul 2018 11:45:52 by Kilian Croese)
- merged to idea Meaningful Error Logs on 07 Aug 2018 01:19:27 by Justin James

Kilian,

Did you try to place in the action that does the remove of your Location Object an Database Exception and catch it?

And after you send a popup with your message?


Abílio Matos



This comment was:
- originally posted on idea 'Delete rule: User friendly error message' (idea created on 02 Jul 2018 11:45:52 by Kilian Croese)
- merged to idea Meaningful Error Logs on 07 Aug 2018 01:19:27 by Justin James

That is the current approach we are using. The Database Exception is a generic exception for everything that can go wrong with the database. So more than an "oops... something went wrong in the database" would be incorrect to report to the user. So I think it is cleaner if I could give a more specific message to the user.



This comment was:
- originally posted on idea 'Delete rule: User friendly error message' (idea created on 02 Jul 2018 11:45:52 by Kilian Croese)
- merged to idea Meaningful Error Logs on 07 Aug 2018 01:19:27 by Justin James

The proper way to do this is to make CRUD wrappers, which should be checking for outstanding references before attempting to delete. Also, if you do this correctly, you can reuse that validation logic to see if the delete should even be allowed in the first place.

J.Ja



This comment was:
- originally posted on idea 'Delete rule: User friendly error message' (idea created on 02 Jul 2018 11:45:52 by Kilian Croese)
- merged to idea Meaningful Error Logs on 07 Aug 2018 01:19:27 by Justin James

Changed the category to Backend




This comment was:
- originally posted on idea 'Delete rule: User friendly error message' (idea created on 02 Jul 2018 11:45:52 by Kilian Croese)
- merged to idea Meaningful Error Logs on 07 Aug 2018 01:19:27 by Justin James

Hi Justin,  Thank you for your response. I could see the advantage of wrapping all the CRUD actions to do some validation, like if the user is actually allowed to perform the action or if the action is valid to be executed. 

I don't really see why you should explicitly check for outstanding references before the attempt to delete. My understanding is that the platform/database is also checking this, so it feels like things are being done twice. 

With the last part you mean that in the wrapper you could include other validations to see that the delete is allowed.


(On a side note. Is there a best practice for the name of the CRUD wrappers? Because I would like to name the wrapper for DeleteEntity, DeleteEntity. This is not possible so the wrapper becomes DeleteEntity2.)



This comment was:
- originally posted on idea 'Delete rule: User friendly error message' (idea created on 02 Jul 2018 11:45:52 by Kilian Croese)
- merged to idea Meaningful Error Logs on 07 Aug 2018 01:19:27 by Justin James

I'm kinda sorta working on an article discussing CRUD wrappers.

The reason why you do the check in advance (in other words, in a separate action that your "delete" wrapper calls, and do not depend 100% on DB rules):

1. Existing records may not be a showstopper in your business logic, just a warning or an advisory.

2. You can call your validation logic IN ADVANCE of attempting a delete, which lets you decide to hide a "delete" button.

3. If you are using a SOFT DELETE pattern, you may want to prevent a delete, but since your "delete" is just flipping a flag and updating the record, the DB rules will never actually prevent the delete.

4. It lets you write very friendly, helpful error messages *that can be translated for multi-locale* (ie: "Cannot delete this invoice line because the payment has already been received.").

5. As you guessed, there may be many delete functions where you want to do validations other than DB rules.

6. A DB rule violation is always a hard exception, which you have to handle carefully. A proper CRUD wrapper lets you handle violations as a soft failure rather than a hard exception.

7. Because you are not handling hard exceptions, it is much easier to log data that helps you problem solve, or hide sensitive data, etc. etc. etc.

Bottom line, yeah, you are duplicating some checks, but seeing huge benefits.

In terms of naming, I used XYZ_Upsert (Update/Insert), XYZ_Remove (hard delete/soft delete), XYZ_GetCanRemove (determine if XYZ can be removed, always called by XYZ_Remove).

I like "Remove" because we are not *always* actually "deleting" data (most apps use a lot of soft deletes), but the goal is always to "remove" the record from use.

J.Ja



This comment was:
- originally posted on idea 'Delete rule: User friendly error message' (idea created on 02 Jul 2018 11:45:52 by Kilian Croese)
- merged to idea Meaningful Error Logs on 07 Aug 2018 01:19:27 by Justin James

I agree with Justin.


I use 

entity__Delete

entity__DeleteAllForABC

entity__CreateOrUpdate

entity__Update 


etc.,


With this methodology you can also add additional functionality e.g.  audit trails for any actions you want to and capture them though an Audit component to a common Audit table, and on;y have to write it once.




This comment was:
- originally posted on idea 'Delete rule: User friendly error message' (idea created on 02 Jul 2018 11:45:52 by Kilian Croese)
- merged to idea Meaningful Error Logs on 07 Aug 2018 01:19:27 by Justin James
Merged this idea with 'Beautify raw database errors' (created on 06 Aug 2018 20:57:12 by Kilian Hekhuis)

This comment was:
- originally posted on idea 'Delete rule: User friendly error message' (idea created on 02 Jul 2018 11:45:52 by Kilian Croese)
- merged to idea Meaningful Error Logs on 07 Aug 2018 01:19:27 by Justin James

We've all been there, trying to delete a record and getting a nice "The DELETE statement conflicted with a REFERENCE constraint" error. Once you know how to read these errors it's easy, but they are mightily confusing for beginning developers. Another one is the "[physical table name] with key 0 not found".

It would be much nicer if the Platform could parse these kind of errors (at least the most common ones) and present them in a user friendlier format.



This comment was:
- originally posted on idea 'Beautify raw database errors' (idea created on 06 Aug 2018 20:57:12 by Kilian Hekhuis)
- merged to idea Delete rule: User friendly error message on 07 Aug 2018 01:10:56 by Justin James


This comment was:
- originally posted on idea 'Delete rule: User friendly error message' (idea created on 02 Jul 2018 11:45:52 by Kilian Croese)
- merged to idea Meaningful Error Logs on 07 Aug 2018 01:19:27 by Justin James
Merged this idea with 'More details on error "String or Binary data is truncated"' (created on 03 Jun 2017 06:14:44 by Ravi Kumar Vakkalanka)

Most of us have seen this error on our application screens. Most of the times we receive this error when we are trying to insert data of length more than what is defined in database table.

If this is the case, Service Center should display more details on what column data is causing this error



This comment was:
- originally posted on idea 'More details on error "String or Binary data is truncated"' (idea created on 03 Jun 2017 06:14:44 by Ravi Kumar Vakkalanka)
- merged to idea Meaningful Error Logs on 07 Aug 2018 01:19:55 by Justin James

Ravi -

That is just an error coming from the database and OutSystems is passing it up.

You should almost never be directly calling the CRUD actions anyways, you should wrap them in something that performs validations. That would be the place to check data length and return a friendlier error message if you want one.

J.Ja



This comment was:
- originally posted on idea 'More details on error "String or Binary data is truncated"' (idea created on 03 Jun 2017 06:14:44 by Ravi Kumar Vakkalanka)
- merged to idea Meaningful Error Logs on 07 Aug 2018 01:19:55 by Justin James

Alternatively, since the Platform knows the length of the Attribute and also knows the length of the string or binary that's being saved, it could perhaps check itself?



This comment was:
- originally posted on idea 'More details on error "String or Binary data is truncated"' (idea created on 03 Jun 2017 06:14:44 by Ravi Kumar Vakkalanka)
- merged to idea Meaningful Error Logs on 07 Aug 2018 01:19:55 by Justin James

I've thought about that as well. It's not hard to make a universal checker for this either way.

But... and this is a BIG but... ever ask yourself "why is the error message from the DB so useless?" It's because DBs don't like to give away information to attackers about column names, table names, etc. A more detailed message may be a security issue. That's why I'm pretty fine with the current implementation, even though it is frustrating from time to time.

J.Ja



This comment was:
- originally posted on idea 'More details on error "String or Binary data is truncated"' (idea created on 03 Jun 2017 06:14:44 by Ravi Kumar Vakkalanka)
- merged to idea Meaningful Error Logs on 07 Aug 2018 01:19:55 by Justin James

I'm fine with a cryptic message, as long as there's some logging in the error log or the like with more details (assuming that someone who has access to the error log doesn't pose a security problem :)).



This comment was:
- originally posted on idea 'More details on error "String or Binary data is truncated"' (idea created on 03 Jun 2017 06:14:44 by Ravi Kumar Vakkalanka)
- merged to idea Meaningful Error Logs on 07 Aug 2018 01:19:55 by Justin James

Also this problem is very severe and difficult to debug when a particular table is having large number of columns and you do not know which column is throwing this error while importing a large set of data from excel into the system. A little more help from platform about row number or column name from excel to pinpoint to exact details would be really useful.



This comment was:
- originally posted on idea 'More details on error "String or Binary data is truncated"' (idea created on 03 Jun 2017 06:14:44 by Ravi Kumar Vakkalanka)
- merged to idea Meaningful Error Logs on 07 Aug 2018 01:19:55 by Justin James

I never have real problems with this error. The error in ServiceCenter drills down to the used entity and from there is just checking which (text) attribute can have the wrong input.

More information would be nice, but then you're comming into the security part what Justin has mentioned.



This comment was:
- originally posted on idea 'More details on error "String or Binary data is truncated"' (idea created on 03 Jun 2017 06:14:44 by Ravi Kumar Vakkalanka)
- merged to idea Meaningful Error Logs on 07 Aug 2018 01:19:55 by Justin James
views
463
Followers
3