Comments (4)
Agreed, personally, every time I would comment "should never happen", it becomes an ASSERT.
Using the ASSERT ID .... CONDITION ... variant might be better though as that enables you turn assertions on/off in different environments.
from styleguides.
@thomham by that logic you are equally suggesting that message type X should also not be used and the whole guideline should be removed. However I think it makes sense, and the author placed good emphasis on using it with great care.
We should raise exceptions for everything we can realistically expect to go wrong, but it's unrealistic to catch every possible thing that can go wrong. Dumps/asserts are for that grey area in between: highly unlikely situations that don't warrant explicit handling but where it would be dangerous to continue.
I also use them for programming errors - e.g. to stop someone from calling a method in an incorrect way; the type of situations that should be caught by the most basic testing.
Regarding ASSERT and unit test, I've grappled with this before, see Is it possible to test ASSERT in ABAP Unit?
Anyway, the point of this issue was to suggest that an assertion is better than message type X receommended by the guideline. And since you raise the point, here's what the responses look like in a web environment:
500 SAP Internal Server Error
ERROR: The current application has triggered a termination with a short dump. (termination: RABAX_STATE)
vs.
500 SAP Internal Server Error
ERROR: The ASSERT condition was violated. (termination: RABAX_STATE)
From a user perspective, I would think that the ASSERT variant is marginally less frustrating as it provides that tiny bit more explanation that something went wrong.
from styleguides.
Here some more arguments which came out of another discussion about ASSERT
and how and if to include it into the clean code document:
-
The two
ASSERT
variants - with and withoutID
- behave completely different and should therefore be looked at differently. While the plainASSERT
triggers a runtime exception which can not be handled, theASSERT ID
variant can be switched off via configuration. The latter feels more like "cranking up the log level to debug". -
It's hard to unit-test an
ASSERT
. If the condition is okay, the assertion goes unnoticed. If it fails, it results in a runtime error that cannot be managed by the unit test framework, such that it is not possible to write a unit test that explicitly provokes this failure.
You can create a test for the private method called by theASSERT
to make sure the detection works, to avoid false positives or false negatives. For a simpleASSERT sy-subrc = 0
. I think we can spare automatic tests. If it should have been a<>
, you will find out immediately anyway. -
From a readability perspective,
ASSERT
can serve as "executable comments" that tell the reader a little more about the program's current expected state. -
ASSERT
seem to fit better to places where my code calls something else, to validate that what happened in those calls matches my expectations, and if not, to uncover programming errors on my side. On the other side, any behavioural change in the called functionality might require de-central rework in all usages. I would prefer having exactly these checks as unit tests on the called method. -
They seem less fit to validate a method's input at the method's start, as the code is likely unable or unwilling to recognise whether the input is internal or external or comes from a program or human user. For these pieces, exceptions seem to be the better choice, for example because they allow the caller to catch the exception, adjust the input, and repeat the call.
For the use of assertions the guidance given by Code Complete (chapter 8.2 in the second edition) is the one I like best:
Use error-handling code for conditions you expect to occur; use assertions for conditions that should never occur
Use assertions to document and verify preconditions and postconditions
Like the executable comments. Your reader (vacation substitute, development support) can identify that you considered the situation and their next job is to find out whether your assumption was faulty or code running before yours is.
For highly robust code, assert and then handle the error anyway
I see a difference between assertions and exceptions, for example, when it comes to preconditions of a method. I stick to this specific topic. With an assertion I describe a contract any caller needs to adhere to. Violation of the contract is similar to a programming error. (The 'inconsistency' some colleagues mentioned above.) If the signature of a method is clear enough and unambiguous then there is no need for additional assertions. Exceptions are the result of input validations (the value is provided by a user or another system or derived from those input) when the caller needs to be informed about invalid input in that specific case. Not sure if the difference becomes clear: one identifies wrong 'calls' of a method in the sense of wrong programming, the other wrong input. The problem often is that the provider of a method cannot really distinguish between the two. Therefore, exceptions are used in most cases.
from styleguides.
If you want to write fault tolerant software where the user might not have access to the backend, then you want to transport an error message to the frontend. Also, you can not test ASSERT statement with unit tests.
from styleguides.
Related Issues (20)
- Strategy regarding translations HOT 2
- Strategy for handling dependencies to system releases HOT 4
- Text on logo not readable in dark mode (Code Review Guide) HOT 3
- [Exploit the test tools] Add CL_AUNIT_AUTHORITY_CHECK to the list? HOT 6
- [Consider decomposing complex conditions] bad use case example HOT 1
- German Translation: Typo HOT 1
- Use assert class instead of ASSERT HOT 12
- Are comments bad or not?
- [Use CHANGING sparingly, where suited] Is it ok to use IMPORTING REF instead of CHANGING? HOT 7
- New rule: prefer inferring types HOT 1
- Abap Exception categories HOT 3
- Use READ-ONLY sparingly - new abap command FINAL HOT 2
- How to add sample code to Clean ABAP? HOT 1
- Unclear explanation of [Use LOCAL FRIENDS to access the dependency-inverting constructor] HOT 5
- Follow rules when abbreviating HOT 1
- "Dead" link at section "split-method-instead-of-boolean-input-parameter" HOT 3
- Chapter "Avoid abbreviations" HOT 7
- [Prefer RAISE EXCEPTION NEW to RAISE EXCEPTION TYPE] In defense of RAISE EXCEPTION TYPE HOT 6
- Prefer ENUM to constants interfaces HOT 1
- [Use | to assemble text] Is a caveat needed in case of translatable texts? HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from styleguides.