On 10/14/2014 8:03 PM, Dicebot wrote:
> On Saturday, 11 October 2014 at 22:06:38 UTC, Walter Bright wrote:
>> All assert actually does is call a function in druntime. You can override and
>> insert your own assert handling function, and have it do as you need. It was
>> deliberately designed that way.
>
> A while ago I have been a looking for a way to throw Exception instead of Error
> for failing assertions inside unittest blocks but druntime didn't seem to
> provide needed context. Do you think this can be a worthy addition?

assert() in a unittest calls:

  __d_unittest(string file, uint line)

which calls:

    onUnittestErrorMsg(string file, size_t line, string msg)

which calls:

    extern (C) void onAssertError( string file = __FILE__, size_t line = __LINE__ ) nothrow
    {
        if( _assertHandler is null )
            throw new AssertError( file, line );
        _assertHandler( file, line, null);
    }

You can use setAssertHandler() to set _assertHandler to do whatever you wish.

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.

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 impossible to have non-fatal unittests and the very reason I was looking for a replacement.

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 impossible to have non-fatal unittests and the very reason I was
> looking for a replacement.

I don't really understand the issue. Unittests are usually run with a separate build of the app, not in the main app. When they are run in the main app, they are run before the app even gets to main().

Why do you need non-fatal unittests?

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 the end prints a final report.

-- 
/Jacob Carlborg

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 how it works.
>
> Any airplane system that detects a fault shuts itself down and the backup is engaged. No way in hell is software allowed to continue that asserted.

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 still it's a "no fail" design you argue against: it shuts down parts one by one when and only when they fail and continues operation no matter what until nothing works and even then it still doesn't fail, just does nothing. The airplane example works against your arguments.

The unreliable design you talk about would be committing a failed transaction, but no, nobody suggests that.

On 10/14/2014 11:23 PM, Jacob Carlborg wrote:
> 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 the end prints a
> final report.

I understand that, but I don't think that is what Dicebot is looking for. He's looking to recover from unittests, not just continue.

On 10/15/14, 4:25 AM, Walter Bright wrote:
> On 10/14/2014 11:23 PM, Jacob Carlborg wrote:
>> 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 the end
>> prints a
>> final report.
>
> I understand that, but I don't think that is what Dicebot is looking
> for. He's looking to recover from unittests, not just continue.

I think this means you can't get stack traces for exceptions thrown in unit tests, right?

On Wednesday, 15 October 2014 at 07:26:03 UTC, Walter Bright wrote:
> On 10/14/2014 11:23 PM, Jacob Carlborg wrote:
>> 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 the end prints a
>> final report.
>
> I understand that, but I don't think that is what Dicebot is looking for. He's looking to recover from unittests, not just continue.

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.

Walter Bright <newshound2@digitalmars.com> writes:

> On 10/14/2014 11:23 PM, Jacob Carlborg wrote:
>> 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 the end prints a final report.
>
> I understand that, but I don't think that is what Dicebot is looking for. He's looking to recover from unittests, not just continue.

That is what I am looking for, just being able to continue from a failed
assert in a unittest.  On iOS, it is easier to build one app with all
unit tests.  This is because I don't know of a way to automate the
download/run of a bunch of smaller unittests.  The test driver catches
Throwables, records failure, then goes on to the next test.  After
catching up on this thread, I feel like unittests should throw
an Exceptions.

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()?