On 09/11/2014 21:33, Walter Bright wrote:
On 11/7/2014 7:00 AM, Bruno Medeiros wrote:
Let me give an example:
double sqrt(double num) {
assert(num = 0);
...
With just this, then purely from a compiler/language viewpoint, if the
assert is
triggered the *language* doesn't know if the
On 11/19/2014 3:59 AM, Bruno Medeiros wrote:
Just to add another one, one that I recently came across while coding, was an
assertion check that I put, which, if it where to fail, would only cause a
redundant use of memory (but no NPEs or access violations or invalid state,
etc.).
If you're
On Sunday, 9 November 2014 at 21:44:53 UTC, Walter Bright wrote:
Having assert() not throw Error would be a reasonable design
choice.
What if you could turn assert() in libraries into enforce() using
a compiler switch?
Servers should be able to record failure and free network
On the other hand I guess HLT will signal SIGSEGV which can be
caught using a signal handler, but then D should provide the
OS-specific infrastructure for obtaining the necessary
information before exiting.
On 11/12/2014 11:40 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Sunday, 9 November 2014 at 21:44:53 UTC, Walter Bright wrote:
Having assert() not throw Error would be a reasonable design choice.
What if you could turn assert() in libraries into enforce() using a
On Wednesday, 12 November 2014 at 20:40:45 UTC, Walter Bright
wrote:
Forgive me for being snarky, but there are text editing
utilities where one can:
Snarky is ok. :)
In any case, compiler switches should not change behavior like
that. assert() and enforce() are completely different.
Well,
On Wednesday, 12 November 2014 at 20:52:28 UTC, Ola Fosheim
Grøstad wrote:
In order to be consistent it with your line of reasoning it
should simply HLT, then a SIGSEGV handler should set up a
preallocated stack, obtain the information and send it off to a
logging service using pure system
On Saturday, 1 November 2014 at 16:42:31 UTC, Walter Bright wrote:
My ideas are what are implemented on airplanes.
For components, not for a system. Nobody said a word against
component design, it's systems that people want to be able to
design, yet you prohibit it.
I didn't originate
On Monday, 3 November 2014 at 03:29:05 UTC, Walter Bright wrote:
On 11/2/2014 3:44 PM, Dicebot wrote:
They have hardware protection against sharing memory between
processes. It's a
reasonable level of protection.
reasonable default - yes
reasoable level of protection in general - no
No
On Friday, 7 November 2014 at 15:00:35 UTC, Bruno Medeiros wrote:
Very well then. But then we'll get to the point where enforce()
will become much more popular than assert to check for contract
conditions. assert() will be relegated to niche and rare
situations where the program cant really
On 11/7/2014 7:00 AM, Bruno Medeiros wrote:
Let me give an example:
double sqrt(double num) {
assert(num = 0);
...
With just this, then purely from a compiler/language viewpoint, if the assert is
triggered the *language* doesn't know if the whole program is corrupted
(formatting the hard
On 11/9/2014 1:12 PM, Dicebot wrote:
On Monday, 3 November 2014 at 03:29:05 UTC, Walter Bright wrote:
It is absolutely different because of scale; having 1K of shared memory is
very different from having 100Mb shared between processes including the stack
and program code.
It is possible to
On Sunday, 9 November 2014 at 21:34:05 UTC, Walter Bright wrote:
On 11/7/2014 7:00 AM, Bruno Medeiros wrote:
assert() is for bug detection, detecting state that should have
never happened. By definition you cannot know it is safe, you
cannot know what caused it.
enforce() is for dealing
On Sunday, 9 November 2014 at 21:59:19 UTC, eles wrote:
On Sunday, 9 November 2014 at 21:34:05 UTC, Walter Bright wrote:
On 11/7/2014 7:00 AM, Bruno Medeiros wrote:
assert() is for bug detection, detecting state that should
have never happened. By definition you cannot know it is
safe, you
On 29/10/2014 21:22, Walter Bright wrote:
On 10/29/2014 5:37 AM, Bruno Medeiros wrote:
On 18/10/2014 18:40, Walter Bright wrote:
As I've said before, tripping an assert by definition means the program
has entered an unknown state. I don't believe it is possible for any
language to make
On Saturday, 1 November 2014 at 15:02:53 UTC, H. S. Teoh via
Digitalmars-d wrote:
I never said component == process. All I said was that at
the OS
level, at least with current OSes, processes are the smallest
unit
that is decoupled from each other.
Which is exactly the statement I call
On 11/2/2014 3:48 AM, Dicebot wrote:
On Saturday, 1 November 2014 at 15:02:53 UTC, H. S. Teoh via Digitalmars-d
wrote:
Which is exactly the statement I call wrong. With current OSes processes aren't
decoupled units at all - it is all about feature set you stick to. Same with any
other units.
On Sunday, 2 November 2014 at 17:53:45 UTC, Walter Bright wrote:
On 11/2/2014 3:48 AM, Dicebot wrote:
On Saturday, 1 November 2014 at 15:02:53 UTC, H. S. Teoh via
Digitalmars-d wrote:
Which is exactly the statement I call wrong. With current OSes
processes aren't
decoupled units at all - it is
On 11/2/2014 3:44 PM, Dicebot wrote:
They have hardware protection against sharing memory between processes. It's a
reasonable level of protection.
reasonable default - yes
reasoable level of protection in general - no
No language can help when that is the requirement.
1. very few
On Monday, 3 November 2014 at 03:29:05 UTC, Walter Bright wrote:
I have considerable experience with what programs can do when
continuing to run after a bug. This was on real mode DOS, which
infamously does not seg fault on errors.
It's AWFUL. I've had quite enough of having to reboot the
On 11/2/2014 8:54 PM, Sean Kelly wrote:
On Monday, 3 November 2014 at 03:29:05 UTC, Walter Bright wrote:
I got into the habit of layering in asserts to stop the program when it went
bad. Do not pass go, do not collect $200 is the only strategy that has a
hope of working under such systems.
The
On Friday, 31 October 2014 at 21:33:22 UTC, H. S. Teoh via
Digitalmars-d wrote:
Again, you're using a different definition of component.
I see no justified reasoning why process can be considered such
component ad anything else cannot.
In practice it is completely dependent on system design
On Friday, 31 October 2014 at 21:33:22 UTC, H. S. Teoh via
Digitalmars-d wrote:
You're using a different definition of component.
System granularity is decided by the designer. You either allow
people design their systems or force your design on them, if you
do both, you contradict yourself.
On Friday, 31 October 2014 at 21:06:49 UTC, H. S. Teoh via
Digitalmars-d wrote:
This does not mean that process isolation is a silver bullet
-- I
never said any such thing.
But made it sound that way:
The only failsafe solution is to have multiple redundant
processes, so when one process
On Wednesday, 29 October 2014 at 21:23:00 UTC, Walter Bright
wrote:
In any case, if the programmer knows than assert error is
restricted to a particular domain, and is recoverable, and
wants to recover from it, use enforce(), not assert().
But all that does is working around the assert's
On Sat, Nov 01, 2014 at 10:52:31AM +, Kagamin via Digitalmars-d wrote:
On Friday, 31 October 2014 at 21:06:49 UTC, H. S. Teoh via Digitalmars-d
wrote:
This does not mean that process isolation is a silver bullet -- I
never said any such thing.
But made it sound that way:
The only
On Sat, Nov 01, 2014 at 09:38:23AM +, Dicebot via Digitalmars-d wrote:
On Friday, 31 October 2014 at 21:33:22 UTC, H. S. Teoh via Digitalmars-d
wrote:
Again, you're using a different definition of component.
I see no justified reasoning why process can be considered such
component ad
On Saturday, 1 November 2014 at 15:02:53 UTC, H. S. Teoh via
Digitalmars-d wrote:
I never said component == process. All I said was that at
the OS
level, at least with current OSes, processes are the smallest
unit
that is decoupled from each other. If you go below that level of
granularity,
On 11/1/2014 3:35 AM, Kagamin wrote:
No misunderstanding, I think that Walter's idea is good, just not always
practical, and that real critical systems don't work the way he describes, they
make more complicated tradeoffs.
My ideas are what are implemented on airplanes. I didn't originate
On 11/1/2014 4:14 AM, Kagamin wrote:
On Wednesday, 29 October 2014 at 21:23:00 UTC, Walter Bright wrote:
In any case, if the programmer knows than assert error is restricted to a
particular domain, and is recoverable, and wants to recover from it, use
enforce(), not assert().
But all that
On 10/10/2014 2:31 AM, Joseph Rushton Wakeling wrote:
I still think that was one of the single most important lessons in probability
that I ever had.
Research shows that humans, even trained statisticians, are spectacularly bad at
intuitive probability.
-- Thinking, Fast and Slow by Daniel
On Thursday, 16 October 2014 at 19:53:42 UTC, Walter Bright wrote:
On 10/15/2014 12:19 AM, Kagamin wrote:
Sure, software is one part of an airplane, like a thread is a
part of a process.
When the part fails, you discard it and continue operation. In
software it works
by rolling back a failed
On Friday, 24 October 2014 at 18:47:59 UTC, H. S. Teoh via
Digitalmars-d wrote:
Basically, if you want a component to recover from a serious
problem
like a failed assertion, the recovery code should be in a
*separate*
component. Otherwise, if the recovery code is within the failing
component,
On Fri, Oct 31, 2014 at 08:15:17PM +, Kagamin via Digitalmars-d wrote:
On Thursday, 16 October 2014 at 19:53:42 UTC, Walter Bright wrote:
On 10/15/2014 12:19 AM, Kagamin wrote:
Sure, software is one part of an airplane, like a thread is a part
of a process. When the part fails, you
On Fri, Oct 31, 2014 at 08:23:04PM +, Kagamin via Digitalmars-d wrote:
On Friday, 24 October 2014 at 18:47:59 UTC, H. S. Teoh via Digitalmars-d
wrote:
Basically, if you want a component to recover from a serious problem
like a failed assertion, the recovery code should be in a *separate*
On Friday, 31 October 2014 at 20:33:54 UTC, H. S. Teoh via
Digitalmars-d wrote:
You are misrepresenting Walter's position. His whole point was
that once
a single component has detected a consistency problem within
itself, it
can no longer be trusted to continue operating and therefore
must be
On Fri, Oct 31, 2014 at 09:11:53PM +, Kagamin via Digitalmars-d wrote:
On Friday, 31 October 2014 at 20:33:54 UTC, H. S. Teoh via Digitalmars-d
wrote:
You are misrepresenting Walter's position. His whole point was that
once a single component has detected a consistency problem within
On 10/31/2014 2:31 PM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Oct 31, 2014 at 09:11:53PM +, Kagamin via Digitalmars-d wrote:
On Friday, 31 October 2014 at 20:33:54 UTC, H. S. Teoh via Digitalmars-d
wrote:
You are misrepresenting Walter's position. His whole point was that
once a
On Friday, 31 October 2014 at 21:33:22 UTC, H. S. Teoh via
Digitalmars-d wrote:
You're using a different definition of component. An
inconsistency in
a transaction is a problem with the input, not a problem with
the
program logic itself. If something is wrong with the input, the
program
can
On 10/31/2014 5:38 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
Transactions roll back when there is contention for resources and/or when you
have any kind of integrity issue. That's why you have retries… so no, it is not
only something wrong with the input. Something is
On Saturday, 1 November 2014 at 03:39:02 UTC, Walter Bright wrote:
Those are environmental errors, not programming bugs, and
asserting for those conditions is the wrong approach.
The point is this: what happens in the transaction engine
matters, what happens outside of it does not matter
On 2014-10-29 22:22, Walter Bright wrote:
Assumptions are not guarantees.
In any case, if the programmer knows than assert error is restricted to
a particular domain, and is recoverable, and wants to recover from it,
use enforce(), not assert().
I really don't like enforce. It encourage the
On 18/10/2014 18:40, Walter Bright wrote:
As I've said before, tripping an assert by definition means the program
has entered an unknown state. I don't believe it is possible for any
language to make guarantees beyond that point.
The guarantees (if any), would not be made by the language, but
On 10/29/2014 5:37 AM, Bruno Medeiros wrote:
On 18/10/2014 18:40, Walter Bright wrote:
As I've said before, tripping an assert by definition means the program
has entered an unknown state. I don't believe it is possible for any
language to make guarantees beyond that point.
The guarantees (if
On 10/27/2014 1:54 PM, Sean Kelly wrote:
On Friday, 24 October 2014 at 19:09:23 UTC, Walter Bright wrote:
You can insert your own handler with core.assertHandler(myAssertHandler). Or
you can catch(Error). But you don't want to try doing anything more than
notification with that - the program
On Tuesday, 14 October 2014 at 15:57:05 UTC, eles wrote:
On Saturday, 4 October 2014 at 05:26:52 UTC, eles wrote:
On Friday, 3 October 2014 at 20:31:42 UTC, Paolo Invernizzi
wrote:
On Friday, 3 October 2014 at 18:00:58 UTC, Piotrek wrote:
On Friday, 3 October 2014 at 15:43:59 UTC, Sean Kelly
On Friday, 24 October 2014 at 19:09:23 UTC, Walter Bright wrote:
You can insert your own handler with
core.assertHandler(myAssertHandler). Or you can catch(Error).
But you don't want to try doing anything more than notification
with that - the program is in an unknown state.
Also be aware
On 9/27/14, 8:15 PM, Walter Bright wrote:
This issue comes up over and over, in various guises. I feel like
Yosemite Sam here:
https://www.youtube.com/watch?v=hBhlQgvHmQ0
In that vein, Exceptions are for either being able to recover from
input/environmental errors, or report them to the
On Fri, Oct 24, 2014 at 03:29:43PM -0300, Ary Borenszweig via Digitalmars-d
wrote:
On 9/27/14, 8:15 PM, Walter Bright wrote:
This issue comes up over and over, in various guises. I feel like
Yosemite Sam here:
https://www.youtube.com/watch?v=hBhlQgvHmQ0
In that vein, Exceptions are
On 10/24/2014 11:29 AM, Ary Borenszweig wrote:
On 9/27/14, 8:15 PM, Walter Bright wrote:
Now, imagine I have an assert in my application. When the web server hits the
assertion it shuts down and the user doesn't get a response. What I'd like to do
is to trap that assertion, tell the user that
in the extreme case, if you want to change anything.
or as a way to shut problem quickly
add to debugging symbols generation algorithm info about file and
line
- Walter?
On Tuesday, 21 October 2014 at 03:25:55 UTC, rst256 wrote:
In this post i forgot make correction machine translation.
I am so sorry!
On Monday, 20 October 2014 at 20:36:58 UTC, eles wrote:
On Saturday, 18 October 2014 at 17:40:43 UTC, Walter Bright
wrote:
On 10/18/2014 8:21 AM, Jacob Carlborg
On Tuesday, 21 October 2014 at 03:25:55 UTC, rst256 wrote:
On Monday, 20 October 2014 at 20:36:58 UTC, eles wrote:
On Saturday, 18 October 2014 at 17:40:43 UTC, Walter Bright
wrote:
On 10/18/2014 8:21 AM, Jacob Carlborg wrote:
On 2014-10-18 07:09, Walter Bright wrote:
Its linking time.
On Saturday, 18 October 2014 at 17:40:43 UTC, Walter Bright wrote:
On 10/18/2014 8:21 AM, Jacob Carlborg wrote:
On 2014-10-18 07:09, Walter Bright wrote:
Which means they'll be program bugs, not environmental errors.
Yes, but just because I made a mistake in using a function
(hitting an
On Wednesday, 22 October 2014 at 15:05:58 UTC, w0rp wrote:
On Saturday, 18 October 2014 at 17:40:43 UTC, Walter Bright
wrote:
On 10/18/2014 8:21 AM, Jacob Carlborg wrote:
On 2014-10-18 07:09, Walter Bright wrote:
never happen, which is like a car turning into King Kong and
It depends on
https://en.wikipedia.org/wiki/Code_smell
Do you read this?
Yes phobos.stdio very smell code. Disagree?
107 КБ of source code olny for call
few functions from stdio. Are you sure that
this code are full correctly?
silly rabbit, y should be positive - may
be becose his used class like this?
the
On Saturday, 18 October 2014 at 17:55:04 UTC, Walter Bright wrote:
On 10/18/2014 9:01 AM, Sean Kelly wrote:
So you consider the library interface to be user input?
The library designer has to make that decision, not the
language.
What about calls that are used internally but also exposed
On Saturday, 18 October 2014 at 17:40:43 UTC, Walter Bright wrote:
On 10/18/2014 8:21 AM, Jacob Carlborg wrote:
On 2014-10-18 07:09, Walter Bright wrote:
Which means they'll be program bugs, not environmental errors.
Yes, but just because I made a mistake in using a function
(hitting an
On 10/18/2014 07:40 PM, Walter Bright wrote:
As I've said before, tripping an assert by definition means the program
has entered an unknown state. I don't believe it is possible for any
language to make guarantees beyond that point.
What about the guarantee that your compiler didn't
On 10/20/2014 1:54 PM, Timon Gehr wrote:
On 10/18/2014 07:40 PM, Walter Bright wrote:
As I've said before, tripping an assert by definition means the program
has entered an unknown state. I don't believe it is possible for any
language to make guarantees beyond that point.
What about the
On Monday, 20 October 2014 at 20:36:58 UTC, eles wrote:
On Saturday, 18 October 2014 at 17:40:43 UTC, Walter Bright
wrote:
On 10/18/2014 8:21 AM, Jacob Carlborg wrote:
On 2014-10-18 07:09, Walter Bright wrote:
Which means they'll be program bugs, not environmental
errors.
Yes, but just
On Saturday, 18 October 2014 at 05:22:54 UTC, Walter Bright wrote:
2. If (1) cannot be done, then write the unittests like:
{
openfile();
scope (exit) closefile();
scope (failure) assert(0);
... use enforce() instead of assert() ...
}
3. In a script that compiles/runs the
On 2014-10-18 06:36, Walter Bright wrote:
This particular subthread is about unittests.
That doesn't make the problem go away.
--
/Jacob Carlborg
On 2014-10-18 07:09, Walter Bright wrote:
Which means they'll be program bugs, not environmental errors.
Yes, but just because I made a mistake in using a function (hitting an
assert) doesn't mean I want to have undefined behavior.
--
/Jacob Carlborg
On Saturday, 18 October 2014 at 05:10:20 UTC, Walter Bright wrote:
I understand that some have to work with poorly written
libraries that incorrectly use assert. If that's the only issue
with those libraries, you're probably lucky :-) Short term, I
suggest editing the code of those
On 10/18/2014 8:21 AM, Jacob Carlborg wrote:
On 2014-10-18 07:09, Walter Bright wrote:
Which means they'll be program bugs, not environmental errors.
Yes, but just because I made a mistake in using a function (hitting an assert)
doesn't mean I want to have undefined behavior.
As I've said
On 10/18/2014 9:01 AM, Sean Kelly wrote:
So you consider the library interface to be user input?
The library designer has to make that decision, not the language.
What about calls that are used internally but also exposed as part of the
library interface?
The library designer has to make
No, right now one can affect the way tests are run by simply
replacing the runner to a custom one and it will work for any
amount of modules compiled in. Beauty of `unittest` block
approach is that it is simply a bunch of functions that are
somewhat easy to discover from the combined sources
On Thursday, 16 October 2014 at 19:53:42 UTC, Walter Bright wrote:
On 10/15/2014 12:19 AM, Kagamin wrote:
Sure, software is one part of an airplane, like a thread is a
part of a process.
When the part fails, you discard it and continue operation. In
software it works
by rolling back a failed
On 2014-10-16 21:35, Walter Bright wrote:
Ok, but why would 3rd party library unittests be a concern? They
shouldn't have shipped it if their own unittests fail - that's the whole
point of having unittests.
They will have asserts in contracts and other parts of that code that is
not unit
On 2014-10-17 10:26, Atila Neves wrote:
Is cleaning up in a unittest build a problem? I'd say no, if it the
tests fail it doesn't make much sense to clean up unless it affects the
reporting of tests failing.
I have used files in some of my unit tests. I would certainly like those
to be
On 2014-10-16 20:50, Walter Bright wrote:
I don't understand why unittests in druntime/phobos are an issue for
users. We don't release a DMD unless they all pass - it should be moot
for users.
There are asserts elsewhere in the code.
--
/Jacob Carlborg
On 2014-10-16 21:31, Walter Bright wrote:
Contract errors in Phobos/Druntime should be limited to having passed it
invalid arguments, which should be documented
That doesn't mean it won't happen.
--
/Jacob Carlborg
On 10/17/2014 9:05 AM, Jacob Carlborg wrote:
On 2014-10-16 21:35, Walter Bright wrote:
Ok, but why would 3rd party library unittests be a concern? They
shouldn't have shipped it if their own unittests fail - that's the whole
point of having unittests.
They will have asserts in contracts and
On 10/17/2014 9:13 AM, Jacob Carlborg wrote:
On 2014-10-16 21:31, Walter Bright wrote:
Contract errors in Phobos/Druntime should be limited to having passed it
invalid arguments, which should be documented
That doesn't mean it won't happen.
Which means they'll be program bugs, not
On 10/17/2014 9:10 AM, Jacob Carlborg wrote:
On 2014-10-17 10:26, Atila Neves wrote:
Is cleaning up in a unittest build a problem? I'd say no, if it the
tests fail it doesn't make much sense to clean up unless it affects the
reporting of tests failing.
I have used files in some of my unit
On 2014-10-15 16:25, Dicebot wrote:
How can one continue without recovering? This will result in any kind of
environment not being cleaned and false failures of other tests that
share it.
I will probably use something else than assert in my unit tests.
Something like assertEq, assertNotEq
On 10/15/2014 7:25 AM, Dicebot wrote:
How can one continue without recovering? This will result in any kind of
environment not being cleaned and false failures of other tests that share it.
Unittest asserts are top level - they shouldn't need recovering from (i.e.
unwinding). Just continuing.
On 10/15/2014 7:35 AM, Dan Olson wrote:
That is what I am looking for, just being able to continue from a failed
assert in a unittest.
Just use enforce() or something similar instead of assert(). Nothing says you
have to use assert() in a unittest.
On 10/15/2014 6:54 PM, Sean Kelly wrote:
I hate to say it, but I'm inclined to treat nothrow the same as in C++, which is
to basically pretend it's not a part of the language. The efficiency is nice,
but not if it means that throwing an Error will cause the program to be
invalid. Please tell me
On Thursday, 16 October 2014 at 07:44:37 UTC, Walter Bright wrote:
On 10/15/2014 6:54 PM, Sean Kelly wrote:
I hate to say it, but I'm inclined to treat nothrow the same
as in C++, which is
to basically pretend it's not a part of the language. The
efficiency is nice,
but not if it means that
Walter Bright newshou...@digitalmars.com writes:
On 10/15/2014 7:35 AM, Dan Olson wrote:
That is what I am looking for, just being able to continue from a failed
assert in a unittest.
Just use enforce() or something similar instead of assert(). Nothing
says you have to use assert() in a
Ola Fosheim Grøstad\ ola.fosheim.grostad+dl...@gmail.com writes:
On Wednesday, 15 October 2014 at 14:25:43 UTC, Dicebot wrote:
How can one continue without recovering? This will result in any
kind of environment not being cleaned and false failures of other
tests that share it.
fork()?
On 10/16/2014 6:46 AM, Sean Kelly wrote:
On Thursday, 16 October 2014 at 07:44:37 UTC, Walter Bright wrote:
Don't throw Errors when you need to unwind. Throw Exceptions. I.e. use
enforce() instead of assert().
I'm more concerned about Phobos. If it uses nothrow and asserts in preconditions
Hi all!
I've read the topic and I am really surprised so many engeneers
arguing for so long and not having systematic approach to the
problem.
As I see it, Walter states that there are eenvironmental errors
and program bugs, which are non-recoverable. So use exceptions
(enforce) for first ones
On 10/16/2014 8:36 AM, Dan Olson wrote:
Walter Bright newshou...@digitalmars.com writes:
On 10/15/2014 7:35 AM, Dan Olson wrote:
That is what I am looking for, just being able to continue from a failed
assert in a unittest.
Just use enforce() or something similar instead of assert().
On Thursday, 16 October 2014 at 18:49:13 UTC, Walter Bright wrote:
On 10/16/2014 6:46 AM, Sean Kelly wrote:
On Thursday, 16 October 2014 at 07:44:37 UTC, Walter Bright
wrote:
Don't throw Errors when you need to unwind. Throw Exceptions.
I.e. use enforce() instead of assert().
I'm more
On Thursday, 16 October 2014 at 18:53:22 UTC, monnoroch wrote:
So if both are true, that clearly means that the right solution
would be to introduce four categories: a cross product of the
obove:
- bugs, that are recoverable
- bugs, that are unrecoverable
- input errors, that are recoverable
-
On Thursday, 16 October 2014 at 06:11:46 UTC, Jacob Carlborg
wrote:
On 2014-10-15 16:25, Dicebot wrote:
How can one continue without recovering? This will result in
any kind of
environment not being cleaned and false failures of other
tests that
share it.
I will probably use something else
On 10/16/2014 12:08 PM, Sean Kelly wrote:
On Thursday, 16 October 2014 at 18:49:13 UTC, Walter Bright wrote:
On 10/16/2014 6:46 AM, Sean Kelly wrote:
On Thursday, 16 October 2014 at 07:44:37 UTC, Walter Bright wrote:
Don't throw Errors when you need to unwind. Throw Exceptions. I.e. use
On 10/16/2014 12:21 PM, Dicebot wrote:
On Thursday, 16 October 2014 at 06:11:46 UTC, Jacob Carlborg wrote:
On 2014-10-15 16:25, Dicebot wrote:
How can one continue without recovering? This will result in any kind of
environment not being cleaned and false failures of other tests that
share
On 10/15/2014 12:19 AM, Kagamin wrote:
Sure, software is one part of an airplane, like a thread is a part of a process.
When the part fails, you discard it and continue operation. In software it works
by rolling back a failed transaction. An airplane has some tricks to recover
from failures, but
On Thursday, 16 October 2014 at 19:35:40 UTC, Walter Bright wrote:
Ok, but why would 3rd party library unittests be a concern?
They shouldn't have shipped it if their own unittests fail -
that's the whole point of having unittests.
Libraries tend to be forked and modified. Libraries aren't
On 10/16/2014 12:56 PM, Dicebot wrote:
On Thursday, 16 October 2014 at 19:35:40 UTC, Walter Bright wrote:
Ok, but why would 3rd party library unittests be a concern? They shouldn't
have shipped it if their own unittests fail - that's the whole point of having
unittests.
Libraries tend to be
On Thursday, 16 October 2014 at 19:56:57 UTC, Dicebot wrote:
Libraries tend to be forked and modified. Libraries aren't
always tested in environment similar to specific production
case.
This seems relevant:
http://www.tele-task.de/archive/video/flash/16130/
On Thursday, 16 October 2014 at 20:18:04 UTC, Walter Bright wrote:
On 10/16/2014 12:56 PM, Dicebot wrote:
On Thursday, 16 October 2014 at 19:35:40 UTC, Walter Bright
wrote:
Ok, but why would 3rd party library unittests be a concern?
They shouldn't
have shipped it if their own unittests fail -
Walter Bright newshou...@digitalmars.com writes:
I don't understand why unittests in druntime/phobos are an issue for
users. We don't release a DMD unless they all pass - it should be moot
for users.
I think some context was lost. This is different. I am making mods to
LDC, druntime, and
On 10/14/2014 8:36 PM, Dicebot wrote:
On Wednesday, 15 October 2014 at 03:18:31 UTC, Walter Bright wrote:
However, the compiler is still going to regard the assert() as nothrow, so the
unwinding from an Exception won't happen until up stack a throwing function is
encountered.
This makes
On 2014-10-15 07:57, Walter Bright wrote:
Why do you need non-fatal unittests?
I don't know if this would cause problems with the current approach. But
most unit test frameworks don't NOT stop on the first failure, like D
does. It catches the exception, continues with the next test and in
On Saturday, 4 October 2014 at 08:08:49 UTC, Walter Bright wrote:
On 10/3/2014 4:27 AM, Kagamin wrote:
Do you interpret airplane safety right? As I understand,
airplanes are safe
exactly because they recover from assert failures and continue
operation.
Nope. That's exactly 180 degrees from
1 - 100 of 432 matches
Mail list logo
