aspose file tools*
The moose likes Java in General and the fly likes why use assertion rather than xception Handling Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "why use assertion rather than xception Handling" Watch "why use assertion rather than xception Handling" New topic
Author

why use assertion rather than xception Handling

Rajesh Kesarwani
Greenhorn

Joined: Apr 04, 2005
Posts: 23
hi all,
assertion is used to document and validate the assumption made about a program at a particular position.and a AssertionEror Exception is thrown if assertion,s binary expression evaluates to false.

can any one tell me this can also be done using simple Exception handling Mechanism.
then why assrtions.
thanx in advance.
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24168
    
  30

Two reasons: first, because the assertion syntax is cleaner, and its purpose is obvious at a glance. Second, because assertions can be turned on and off at runtime, automatically.


[Jess in Action][AskingGoodQuestions]
Jesus Angeles
Ranch Hand

Joined: Feb 26, 2005
Posts: 2046
assertions is not made for documentation.

yes, assertions is not made to replace exceptions. exception stays, and used as usual.

while exceptions tag along up to implementation/production, assertions is usually for development stage.

by the word 'assert', it merely pacifies the user that certain conditions persist, at certain points in the system, while doing development.
Stuart Gray
Ranch Hand

Joined: Apr 21, 2005
Posts: 410
Perhaps also that assertions are designed to catch 'can't happen' errors; a fully tested and released program should not contain any assertion errors because they have hopefully all been removed by the testing. But such a program can still generate exceptions for events that are unexpected (such as file not found, I/O exception, etc).
Rick O'Shay
Ranch Hand

Joined: Sep 19, 2004
Posts: 531
Three Important Concepts and One Abomination

*Expected Recoverable Input Errors

If you receive incorrect data from a web service or a file or a user do you throw an exception or treat it like an expected use-case? What if they don't check an "I agree" box? Is that an exception or a normal use-case? Logically speaking that's not an error or an exception but a normal part of operation.

*Exceptions

If the printer is not available or a file is not available or you run out of memory or a socket dies or the stack overflows, that's an exceptional situation. Why didn't you check to see if that printer or file was available first? As for the stack or memory overflow, you should have scaled your application better, but even if you did not there's nothing you can do. An exception is appropriate at that point.

*CheckedExceptions

Don't use them. They are an abomination.

*Assertions

With assertions you catch programming errors. You should test all of your code and assertions will keep you honest if you don't. Use them everywhere including public method arguments, contrary to Sun's suggestion. Assetions tell you quickly and effectively that your code is broken without cluttering up the logic of the program to check for coding errors. Checking for coding errors with code is a bit circular.


Summary

- Input errors should be handled by the application where appropriate.
- Unchecked exceptions are thrown when there's nothing you can do once the situation occurs.
- Checked exceptions are an abomination, just this side of evil.
- Assertions are used to check for correctness but they require that you test your code and exercise the conditions being checked.

[ August 18, 2005: Message edited by: Rick O'Shay ]
Stefan Wagner
Ranch Hand

Joined: Jun 02, 2003
Posts: 1923

Why didn't you check to see if that printer or file was available first?

I did, but between checking and printing the file the printer turned offline and the file was deleted.

I like checked exceptions.
Working with a powerful IDE like eclipse or configurable editors which surround your code with an exception-template makes them usable.


http://home.arcor.de/hirnstrom/bewerbung
Rick O'Shay
Ranch Hand

Joined: Sep 19, 2004
Posts: 531
OK, so you checked the printer first but the fuse blew. No worries, a runtime exception or an error will kill your program. That thread was doomed, there's no way to save it.

As far as Eclipse goes, it's not typing in try/catch/finally that's the problem. It's a) eating exceptions, b) using them as flow control. Not to mention the maintenance issue: try adding a new checked exception to some commonly used base method, yikes!

I love exceptions and the idea that, if I want to and I know what I am doing I can catch 'em. I don't like checked exceptions.
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

Assertions are used for testing. They are a debugging tool of sorts used to validate your code.

I am still not sold on the evilness of checked exceptions. Are you suggesting that all checked exceptions should be unchecked exceptions? If so, why?
Rick O'Shay
Ranch Hand

Joined: Sep 19, 2004
Posts: 531
I addressed my main complaints already but here's a discussion by some industry experts:

http://www.artima.com/intv/handcuffs.html

My main beef is that they typically get eaten or punted up the tree where they are eaten. On occassion they are handled correctly. So, the punt/eat becomes a lot of noise where as the "handled correctly" case will be done whether it is checked or unchecked.

Now, what I do like about checked exceptions is that they tell me what exceptions are thrown. What I don't like is that's unreliable because a runtime exception (which smells like a checked exception cover up) is not required to be advertised. A reporting tool would be great. Anyway, it's academic because checked exceptions aren't going anywhere. Does it bother me? No, there are benefits so in some sense it's evil like beer is evil.
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
Avoid assertions - they are a flawed attempt at a fail-early mechanism. They don't belong in any language using the provided semantics, let alone a static typed language - it directly contravenes the purposes of static typing; this fact is just not taught in schools or Sun marketing literature.


Tony Morris
Java Q&A (FAQ, Trivia)
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

Originally posted by Rick O'Shay:
I addressed my main complaints already but here's a discussion by some industry experts:

http://www.artima.com/intv/handcuffs.html

My main beef is that they typically get eaten or punted up the tree where they are eaten. On occassion they are handled correctly. So, the punt/eat becomes a lot of noise where as the "handled correctly" case will be done whether it is checked or unchecked.

Now, what I do like about checked exceptions is that they tell me what exceptions are thrown. What I don't like is that's unreliable because a runtime exception (which smells like a checked exception cover up) is not required to be advertised. A reporting tool would be great. Anyway, it's academic because checked exceptions aren't going anywhere. Does it bother me? No, there are benefits so in some sense it's evil like beer is evil.



so you think checked exceptions are bad because they lead the programmer to mishandle unchecked exception possibility?

I think the unchecked exceptions in Java all point out errors in your code. Kind of like what an assert is for!? but in the end you do have to handle unchecked exceptions too. Its interesting.
Rick O'Shay
Ranch Hand

Joined: Sep 19, 2004
Posts: 531
>> so you think checked exceptions are bad because they lead the programmer to mishandle unchecked exception possibility?

That's definitely part of my rationale. It promotes catch-and-consume thus masking problems at runtime that would otherwise be visible. That's clearly not unique to checked exceptions but unchecked doesn't yell "catch me!".

The astute programmer will determine there is nothing they can do and simply add that exception to the throws clause, but that has new problems. Now it ripples all the way up the call tree. You add one method that introduces and exception, and tons of code has to change.

It's really an abomination. A misguided attempt to enforce handling of exceptions that a) didn't, b) created a maintenance headache.
[ August 27, 2005: Message edited by: Rick O'Shay ]
Rick O'Shay
Ranch Hand

Joined: Sep 19, 2004
Posts: 531
Originally posted by Tony Morris:
Avoid assertions - they are a flawed attempt at a fail-early mechanism. They don't belong in any language using the provided semantics, let alone a static typed language - it directly contravenes the purposes of static typing; this fact is just not taught in schools or Sun marketing literature.


I disagree that it contravenes static typing anymore than primitives contravene objects. Assertions are not static typing, we agree on that, but isn't that obvious? So why teach that explicitly? Teach static typing, then assertions (design by contract) and point out the difference if you feel you must.

Assertions are an effective and easy-to-use runtime validation strategy. They are fail-early in the sense that you want to catch errors before a product gets to QA and, by extension, customers.

Now, do they belong in any language? Yes, languages that do not have a preprocessor gain a material benefit from this.

You should use assertions frequently.
[ August 27, 2005: Message edited by: Rick O'Shay ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Rick O'Shay:

Teach static typing, then assertions (design by contract) and point out the difference if you feel you must.


I agree with most of what you write, but Java assertions don't have much to do with design by contract. In design by contract, assertions (pre- and post-conditions) *are* statically type checked, in the sense that subclasses are only allowed to weaken pre- and strengthen post-conditions (which makes sure that Liskov's Substitution Principle isn't violated).

Still I find that assertions are quite useful. In fact the only thing I don't like about how they are implemented in Java is that they are disabled by default.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Tony Morris:
Avoid assertions - they are a flawed attempt at a fail-early mechanism. They don't belong in any language using the provided semantics, let alone a static typed language - it directly contravenes the purposes of static typing; this fact is just not taught in schools or Sun marketing literature.


How does checking for a condition and throwing an exception if the condition isn't satisfied contravene static type checking???
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
In my experience, checked exceptions hamper reuse. When you try to mercilessly remove duplicated code logic, you often find that there is some specific code that can make use of some generic code, which needs to call back into some specific code. If the inner specific code needs to throw an exception that the outer specific code needs to catch, the generic code suddenly needs to declare that exception (unless it's a RuntimeException).

Just think about implementing a Visitor where some of the visit methods need to throw an exception.

Of course you can work around this problem, but it's no fun...
Rick O'Shay
Ranch Hand

Joined: Sep 19, 2004
Posts: 531
>> Java assertions don't have much to do with design by contract...
>> In design by contract, assertions statically type checked

A non-sequitur IMO. Bob uses Eiffel and his contracts are enforced by the compiler. Alice uses Java and her contracts are enforced by the JVM. Both implementations are otherwise identical. Alice then adds unit tests which validate the assertions as part of the build.

The customer can't tell the difference. Both are design by contract. One has explicit compiler support, the other does not. Clearly the implicit compiler support has several significant advantages, however, they both have precisely the same intent. So if one is design-by-contract so is the other, albeit a poor man's version.
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

Originally posted by Rick O'Shay:
>> so you think checked exceptions are bad because they lead the programmer to mishandle unchecked exception possibility?

That's definitely part of my rationale. It promotes catch-and-consume thus masking problems at runtime that would otherwise be visible. That's clearly not unique to checked exceptions but unchecked doesn't yell "catch me!".


Well this i dont agree with. I do not think it promotes catch-and-consume. Thats just a bad programmer and there is nothing you can do about that. I heard that from some JDO folks too. Claiming that during their design before they were done they had to mask all these exceptions they were not prepared to deal with.

Originally posted by Rick O'Shay:

The astute programmer will determine there is nothing they can do and simply add that exception to the throws clause, but that has new problems. Now it ripples all the way up the call tree. You add one method that introduces and exception, and tons of code has to change.


Well there are certainly many things you can do. I see the problem though. You already need to be doing this stuff for runtime exceptions that can occur in the same code such as, Out of memory errors. So whats the point of forcing specific handling just for a particular one. Yes I see it. I'll let this soak in for a few hours to see if I flip or flop again
Rick O'Shay
Ranch Hand

Joined: Sep 19, 2004
Posts: 531
>> Well there are certainly many things you can do.

I think you misinterpreted my remarks somewhat. It's a given that you catch any and all exceptions you can fix, checked or otherwise. What the astute programmer won't do is eat an exception they can't deal with. They will declare that they throw it and that's where the maintenance problem comes in.

You could add one method call to some existing code and get caught between a rock and a hard place. Now if they were all unchecked you would be in good shape. There are plenty of things in Java that are there to protect against poor programming.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Rick O'Shay:
A non-sequitur IMO. Bob uses Eiffel and his contracts are enforced by the compiler. Alice uses Java and her contracts are enforced by the JVM. Both implementations are otherwise identical. Alice then adds unit tests which validate the assertions as part of the build.


An assertion is not a contract, because there is no automated way to make sure that subclasses conform to it.

In DBC, what you often will do is define a contract for *an interface*. You then automatically know that all implementing classes conform to that contract. There is no way to do that with Java assertions.

(You *can* do something like that with unit tests, but I think it would be kind of a stretch to call that DBC, too.)


The customer can't tell the difference. Both are design by contract.


The customer can't even tell wether you are using DBC at all, so that's hardly an argument, is it?
Rick O'Shay
Ranch Hand

Joined: Sep 19, 2004
Posts: 531
>> An assertion is not a contract, because there is no automated way to make sure that subclasses conform to it.

It's not stretching the definition to stipulate that you need to enforce using unit tests. We have to make sure we don't confuse a given practice with direct language support for that practice. Where's the smoke filled room where powerful men chisel these definitions in stone? There is none, like many concepts, DBC is a little fuzzy around the edges.

Now, I am not suggesting that Java implements DBC but that assertions are an important supporting facility. It's hard to argue against that position.

>> The customer can't even tell wether you are using DBC at all, so that's hardly an argument, is it?

Think about what you are implying there: that DBC has no detectable effects. Clearly that's not the case or it would be a pointless pursuit. DBC results in materially significant code quality improvements. The customer sees that effect and they see that they are getting product sooner.

In an nutshell you were saying it's not automated so it doesn't count as DBC. I was saying it requires extralinguistic support but that asserts are an enabling tool for DBC and that the end result would be the same.

There's no question asserts directly support DBC and that you can practice DBC with a combination of asserts and pre-release testing. There's nothing about that you can consider a "stretch" of the definition of DBC. Now, if I was saying that Java had comprehensive support for DBC, then you would have a complaint.
[ August 28, 2005: Message edited by: Rick O'Shay ]
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
The very fact that you can turn assertions on/off is enough to invalidate them as a useful mechanism; I won't bother delving any further, since it is merely wasting precious energy.
Rick O'Shay
Ranch Hand

Joined: Sep 19, 2004
Posts: 531
>> The very fact that you can turn assertions on/off is enough to invalidate them as a useful mechanism.

They are being used pervasively to great effect. It's a language change that was given the greatest of scrutiny by the JCP. To come along and state that assertions are useless and/or invalid, requires a rational argument. If you consider it a waste of precious energy to back it up, save a little more and don't presume to speak with authority on the subject in the first place.
[ August 28, 2005: Message edited by: Rick O'Shay ]
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
I think it's obvious with a little thought. I encourage thought, and I hate preaching. I reserve the right to make assertions (oh the pun!) without any basis whatsoever, much like everyone else does. "Because everyone else does it", or "it works for lots of people" is unsound.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Tony Morris:
The very fact that you can turn assertions on/off is enough to invalidate them as a useful mechanism.


I guess that for some people that might actually make them more useful - for example if they have expensive asserts and/or very performance sensitive production environments.

I'd prefer if they were enabled by default, though.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Rick, you are right - I was more speaking about DBC as a language feature, less as a development technique.

Still, as a development technique, DBC means to write those contracts *before* writing the code that implements them. So a language feature that you have to intermingle with the rest of the code doesn't sound like a very good match for implementing DBC to me.

Frankly, an assert statement in Java isn't much more than a conditional exception that can be disabled at runtime, is it?
Rick O'Shay
Ranch Hand

Joined: Sep 19, 2004
Posts: 531
>> an assert statement in Java isn't much more than a conditional exception that can be disabled at runtime...

IMO it's substantially more than that. The assert is concise and that has value. Moroever, it stands out as a check for programmer errors. It doesn't obscure the business logic. That's important and its one of the benefits of exceptions as well.

As far as the ability to turn them on by default, I do not agree with that. First, you don't want them in production code so the more prudent choice is to not enable. Second, it's on by default in the build script developers use, so it's really not a burden. Finally, selective enabling requires that it be off by default; there is no other practical choice.
Rick O'Shay
Ranch Hand

Joined: Sep 19, 2004
Posts: 531
>> I think it's obvious with a little thought.

Apparently the expert panel overlooked the reason why asserts are invalid/useless as you claim. At least I'm in good company because it escapes me, too.

>> I encourage thought, and I hate preaching.

Think about what you're saying there. It's a direct contradiction on several levels in addition to being invalid and possibly undermining the very freedom that allows you to make that statement in the first place. Why? It's obvious so I won't waste any bandwidth justifying it. I encourage you to think about it.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Rick O'Shay:
>> an assert statement in Java isn't much more than a conditional exception that can be disabled at runtime...

IMO it's substantially more than that. The assert is concise and that has value. Moroever, it stands out as a check for programmer errors. It doesn't obscure the business logic. That's important and its one of the benefits of exceptions as well.


OK, granted, my statement was a little bit of an exaggeration. Still, full DBC support could have been so much more that assert really looks like a cheap replacement. Your mileage may vary, I guess.

As far as the ability to turn them on by default, I do not agree with that. First, you don't want them in production code so the more prudent choice is to not enable.


Well, that's what I disagree with. Why would I want them to be disabled in production *by default*?

In fact, at work we decided to not use asserts, but implemented our own mechanism (an Ensure class) that can't be disabled. In my experience, that has only helped us to improve quality.

Second, it's on by default in the build script developers use, so it's really not a burden.


If I wanted to have asserts disabled in production, I'd certainly agree!


Finally, selective enabling requires that it be off by default; there is no other practical choice.


Selective *dis*abling seems to be an obvious alternative choice to me...
Rick O'Shay
Ranch Hand

Joined: Sep 19, 2004
Posts: 531
I don't see a pratical value in selectively disabling asserts. It's tough to focus on one or two items when you have to specify what you do not want. Sort of like asking what does 2 + 2 not equal and then coming back when the Sun is an Orange Giant and you're still listing off what it's not

The reason you do not want them enabled in production are thread-killing unrecoverable assert exceptions. This really amplifies the need to combine assertions with solid testing. C++ programmers have used debug enabled asserts for years.

#define ASSERT( expression ) #IFDEF DEBUG if((expression) == FALSE ) throw AssertException() #ENDIF

If you do not catch these problems in testing the idea is that you are better off crossing your fingers, closing your eyes and hoping for the best. I guess it's debatable, but it's what most folks do now anyway.
[ August 29, 2005: Message edited by: Rick O'Shay ]
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608

the expert panel

I take it you haven't had many dealings with JSR teams.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Tony Morris:

I take it you haven't had many dealings with JSR teams.


Tony, please keep in mind that our "be nice" rule doesn't only apply to dealing with JavaRanch members. You are on a slippery slope here.

There is nothing wrong with disagreeing with JSR teams (I do so from time to time, too), or with questioning how the members are selected, but what you are doing is close to rude without adding much value to the discussion.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Rick O'Shay:
I don't see a pratical value in selectively disabling asserts. It's tough to focus on one or two items when you have to specify what you do not want. Sort of like asking what does 2 + 2 not equal and then coming back when the Sun is an Orange Giant and you're still listing off what it's not


Sorry, you lost me here. But perhaps I just don't understand your assumed usage pattern for selective enabling.

Anyway, it even wouldn't be too hard to implement it that way that you can specify which asserts you want to be enabled, with "ALL" being the default.

If you do not catch these problems in testing the idea is that you are better off crossing your fingers, closing your eyes and hoping for the best. I guess it's debatable, but it's what most folks do now anyway.


I know that many folks do it that way, but in my not so humble opinion it's a strange way of tackling the problem. After all, a failed assertion means that something happened that shouldn't have happened. That is, the system is in an illegal state. It's quite unlikely that it will magically recover from that state - it's much more likely that it gets worse: data gets corrupted which only gets noticed much later, wrong results are taken as good results etc. pp. If nothing else, the system will fail later without an easy way to find out how it got into that state.

And it is actually much easier to write a system that gracefully recovers from assertion failures than one that recovers from an arbitrary invalid state.

With other words, in my opinion "crossing fingers and hoping for a wonder" hardly qualifies as professional behaviour.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
By the way, ignoring an exception and just continuing was exactly what caused the Ariane 5 incident.
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
Originally posted by Ilja Preuss:


Tony, please keep in mind that our "be nice" rule doesn't only apply to dealing with JavaRanch members. You are on a slippery slope here.

There is nothing wrong with disagreeing with JSR teams (I do so from time to time, too), or with questioning how the members are selected, but what you are doing is close to rude without adding much value to the discussion.


I didn't intend to be rude, but quite often bluntness is misconceived as such. The premise of some "expert group" is not enough to make a point; quite the contrary if anything. Having worked on the J2EE spec. last year, and now the J2SE spec. this year, I have had some intimate dealings with JSR groups. They are hardly "expert groups", despite what the brochure says.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Tony Morris:

I didn't intend to be rude, but quite often bluntness is misconceived as such.


I didn't assume that you intended to be rude - that's why I wanted to give you feedback on how your post can be perceived, so that you can reconsider your communication style.

And I don't understand why you wrote "misconceived" instead of "conceived".
Rick O'Shay
Ranch Hand

Joined: Sep 19, 2004
Posts: 531
Originally posted by Ilja Preuss:
By the way, ignoring an exception and just continuing was exactly what caused the Ariane 5 incident.


Couple things. First, if you you assertions they are disabled in production. You then must provide explicit runtime conditionals if you want to catch the same errors. If you do that, you are checking for expected problems, which is not the purpose of asserts. I'm getting the feeling the essence of asserts are being missed.

Assume assertions are the right mechanism for these particular tests. Unless you check every possible data value in every combination (utterly impracticle) you are already crossing your fingers and hoping for the best if they are disabled. Pretending otherwise is unprofessional.

Crashing the system deliberately is also unprofessional. Assertions are effectively compile errors. You validate your method contracts using rigorous testing, then you disable the checks in production. They check for programmer errors, not logical business errors.

The professional knows where there is an acceptable risk level, it's rather glib to assume you have left nothing to chance. There's simply no way to test every data value in every combination. Unlike the average dud developer you, the astute practitioner, have several stratgies in place to ensure a robust product.

Now, as for turning off assertions causing major problems, that falls under the heading "unprofessional". That person did not get assertions. They added an assert instead of a critical runtime conditional.

Now, as to the selective disabling. You have 100 packages and 1000 classes. You want to enable assertions on two classes. Good luck disabling the other 998 classes if you have then all enabled by default. That is a valid reason to not enable by default, namely, that the usual use case is to turn all on, all off, or selectively turn on a few. In other words, the Sun will burn out before you can tell me what 2 + 2 does not equal. Get it
[ August 30, 2005: Message edited by: Rick O'Shay ]
Rick O'Shay
Ranch Hand

Joined: Sep 19, 2004
Posts: 531
Assertions

Assertions check for correct code use. They detect coding errors only. I'm convinced many are missing that critical point. They are not user input errors; they are not execeptions. You must be able to make that distinction or you cannot effectively apply assert.

The conditions you are asserting must be tested as rigorously. You are picking up where the compiler leaves off. The assertions must not contain side effects as they should be turned off in production. This increases performance and it gives anything that slipped through the cracks the opportunity to self-correct or at least carry on without killing the thread.

I think that last part, disabling in production, is where the controversy is. I'm certainly not 100% sold on the idea of turning them off. The performance issue is a dubious reason. IMO, turning off is based more on the spirit of assertions being that of catching programmer errors before shipping. Otherwise, let the application run its course. I can see both sides of the on/off argument.
[ August 30, 2005: Message edited by: Rick O'Shay ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Rick O'Shay:
First, if you you assertions they are disabled in production. You then must provide explicit runtime conditionals if you want to catch the same errors. If you do that, you are checking for expected problems, which is not the purpose of asserts. I'm getting the feeling the essence of asserts are being missed.


I don't think so. As you said below, no matter how much you test, there is always a chance of a bug being in the production system. And if there is, I want to know as early as possible, before it can wreak havoc. That's why I don't want to turn of asserts.

Assume assertions are the right mechanism for these particular tests. Unless you check every possible data value in every combination (utterly impracticle) you are already crossing your fingers and hoping for the best if they are disabled. Pretending otherwise is unprofessional.


I don't think I understand what you are getting at here...

Anyway, I don't think that having bugs being concealed and hoping for the best is very professional. I'd rather prefer being proud about the quality of the system and being accountable for bugs that are still in there.


Crashing the system deliberately is also unprofessional.


My point is that it's not the assert that is the "crash", but the condition that toggles the assert. Even when disabling the assert, the problem is still there, it's just not as visible.

Assertions are effectively compile errors. You validate your method contracts using rigorous testing, then you disable the checks in production. They check for programmer errors, not logical business errors.


You seem to equate programmer errors with compile time errors here, with the conclusion that they shouldn't show up in production? I have problems following that train of thought...

The professional knows where there is an acceptable risk level, it's rather glib to assume you have left nothing to chance. There's simply no way to test every data value in every combination. Unlike the average dud developer you, the astute practitioner, have several stratgies in place to ensure a robust product.


Yes. My argument is that disabling asserts doesn't make a product more robust. It just conceals problems. If you want a robust product, you should work on making it robust in the presence of enabled asserts, which is quite possible.

Now, as for turning off assertions causing major problems, that falls under the heading "unprofessional". That person did not get assertions. They added an assert instead of a critical runtime conditional.


It's not the disabled assert that is causing the major problem, it's disabling the assert that protracts and potentially multiplies the already existing problem.

Now, as to the selective disabling. You have 100 packages and 1000 classes. You want to enable assertions on two classes. Good luck disabling the other 998 classes if you have then all enabled by default. That is a valid reason to not enable by default, namely, that the usual use case is to turn all on, all off, or selectively turn on a few.


You are right, there are those three usual use cases. And it still seems to me that "turn all on" could be the default without affecting the other two use cases at all. You could still have the flag "have only those two classes assertions enabled for", couldn't you? No need to explicitely disable all other classes.

(It would work like an Ant fileset - per default, all files in a folder are included, but as soon as you provide an include directive, only those files are included.)
Rick O'Shay
Ranch Hand

Joined: Sep 19, 2004
Posts: 531
>> Anyway, I don't think that having bugs being concealed and hoping for the best is very professional.

In addition to the mountain of best practices I am adding asserts with rigorous unit tests. What you are suggesting is that regardless of how well you build your system and how rigorous your testing, if you turn off asserts it's unprofessional. In fact disabling is the recommended practice. Following that recommendation is not unprofessional IMO.

>> I'd rather prefer being proud about the quality of the system and being accountable for bugs that are still in there.

You can do that without killing a user's thread when a constraint violation slips through the cracks. I think that is the point of contention. Is it better to crash the thread or continue on? In the case of assertions (keeping in mind we still have all of the business logic and exceptions) the consensus appears to be continue. I agree it is not a cut and dried issue.

>> When when disabling the assert, the problem is still there, it's just not as visible.

Of course. Nobody disputes that. See previous paragraph.

>> You seem to equate programmer errors with compile time errors here, with the conclusion that they shouldn't show up in production?

Precisely. You have to have your business logic to take care of expected "errors" and exceptions for unexpected environmental errors. The assertions test errors that the programmer makes that are outside the scope of the compiler. If the unit test fails the build fails just as hard as some source not compiling.

>> Yes. My argument is that disabling asserts doesn't make a product more robust. It just conceals problems

If you fail to adequately test then we agree. Testing and asserts are inextricably bound.

>> It still seems to me that "turn all on" could be the default without affecting the other two use cases at all.

Agreed, as long as you have the option of turning them all off, too.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: why use assertion rather than xception Handling
 
Similar Threads
exception handling
Assertion.....
Seam and persistence context management
can'n build jsp use weblogic!
weblogic.utils.AssertionError !