On Wed, 13 Jul 2016 13:50:00 +, ketmar wrote:
> https://dlang.org/library/object/throwable.html
>
> "In principle, one should not catch Throwable objects that are not
> derived from Exception, as they represent unrecoverable runtime errors.
> Certain runtime guarantees may fail to hold when
On Wednesday, 13 July 2016 at 13:46:44 UTC, Chris Wright wrote:
On Wed, 13 Jul 2016 13:31:03 +, ketmar wrote:
On Wednesday, 13 July 2016 at 13:13:45 UTC, Chris Wright wrote:
as Error can be thrown anywhere along the way (think, for
example, about
RangeError in expression with
On Wed, 13 Jul 2016 13:31:03 +, ketmar wrote:
> On Wednesday, 13 July 2016 at 13:13:45 UTC, Chris Wright wrote:
> as Error can be thrown anywhere along the way (think, for example, about
> RangeError in expression with side-effects), and stack unwinding is not
> guaranteed (but *may* happen,
On Wednesday, 13 July 2016 at 13:13:45 UTC, Chris Wright wrote:
as Error can be thrown anywhere along the way (think, for
example, about RangeError in expression with side-effects), and
stack unwinding is not guaranteed (but *may* happen, and may
happen partially), the program *is* in
On Sun, 10 Jul 2016 16:57:49 +, ketmar wrote:
> On Sunday, 10 July 2016 at 16:47:31 UTC, Chris Wright wrote:
>> You do need a try/catch in every annotated function to catch runtime
>> exceptions like OutOfMemoryError.
>
> as a side note: it is even not guaranteed that one *can* catch Error.
On Wednesday, 13 July 2016 at 11:16:03 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 13 July 2016 at 11:06:54 UTC, ketmar wrote:
On Wednesday, 13 July 2016 at 11:05:32 UTC, Ola Fosheim
Grøstad wrote:
Wrong. Just because a language-spec says a compiler writer
does not have to care about a
On Wednesday, 13 July 2016 at 11:06:54 UTC, ketmar wrote:
On Wednesday, 13 July 2016 at 11:05:32 UTC, Ola Fosheim Grøstad
wrote:
Wrong. Just because a language-spec says a compiler writer
does not have to care about a particular type of input does
not mean that the compiler and programmer
On Wednesday, 13 July 2016 at 11:05:32 UTC, Ola Fosheim Grøstad
wrote:
Wrong. Just because a language-spec says a compiler writer does
not have to care about a particular type of input does not mean
that the compiler and programmer cannot verify the data to be
valid.
you can't. by
On Wednesday, 13 July 2016 at 10:33:52 UTC, ketmar wrote:
On Wednesday, 13 July 2016 at 10:14:41 UTC, Max Samukha wrote:
Undefined implies there *may* be something to save.
but you have no way to know what.
Wrong. Just because a language-spec says a compiler writer does
not have to care
On Wednesday, 13 July 2016 at 10:14:41 UTC, Max Samukha wrote:
Undefined implies there *may* be something to save.
but you have no way to know what.
That is why programs like Steinberg Cubase do not simply bail
out on failure, but give users a chance to save a copy of their
work.
that's
On Wednesday, 13 July 2016 at 10:14:24 UTC, Ola Fosheim Grøstad
wrote:
That is a meaningless statement. The program is never in a
state. The program is the input, the source code.
no.
On Wednesday, 13 July 2016 at 09:04:20 UTC, ketmar wrote:
On Wednesday, 13 July 2016 at 07:14:04 UTC, Max Samukha wrote:
Undefined does not imply corrupt.
undefined means "undefined". there is nothing more to save,
nothing more to do, as you can't rely on a single bit. this
is... definition
On Wednesday, 13 July 2016 at 09:53:31 UTC, ketmar wrote:
On Wednesday, 13 July 2016 at 09:12:56 UTC, Ola Fosheim Grøstad
wrote:
Undefined by the language is not the same as unknown in a
concrete instance. It simply means that such constructs are
not part of the specified language.
"program
On Wednesday, 13 July 2016 at 09:12:56 UTC, Ola Fosheim Grøstad
wrote:
Undefined by the language is not the same as unknown in a
concrete instance. It simply means that such constructs are not
part of the specified language.
"program is in undefined state"? that is what written in the
specs.
On Wednesday, 13 July 2016 at 09:04:20 UTC, ketmar wrote:
On Wednesday, 13 July 2016 at 07:14:04 UTC, Max Samukha wrote:
Undefined does not imply corrupt.
undefined means "undefined". there is nothing more to save,
nothing more to do, as you can't rely on a single bit. this
is... definition
On Wednesday, 13 July 2016 at 07:14:04 UTC, Max Samukha wrote:
Undefined does not imply corrupt.
undefined means "undefined". there is nothing more to save,
nothing more to do, as you can't rely on a single bit. this is...
definition of undefined.
relying on defined state with undefined
On Sunday, 10 July 2016 at 16:57:49 UTC, ketmar wrote:
On Sunday, 10 July 2016 at 16:47:31 UTC, Chris Wright wrote:
You do need a try/catch in every annotated function to catch
runtime exceptions like OutOfMemoryError.
as a side note: it is even not guaranteed that one *can* catch
Error. and
On 7/11/2016 9:10 PM, Chris Wright wrote:
On Mon, 11 Jul 2016 06:13:00 -0700, Walter Bright wrote:
On 7/9/2016 8:02 PM, Superstar64 wrote:
Would it be possible and a good idea to have a language feature that
allows some exceptions to use error code code generation.
If you want to return an
On Mon, 11 Jul 2016 06:13:00 -0700, Walter Bright wrote:
> On 7/9/2016 8:02 PM, Superstar64 wrote:
>> Would it be possible and a good idea to have a language feature that
>> allows some exceptions to use error code code generation.
>
> If you want to return an error code, return an error code.
On Monday, 11 July 2016 at 13:20:50 UTC, Walter Bright wrote:
On 7/10/2016 10:21 PM, Ola Fosheim Grøstad wrote:
On Monday, 11 July 2016 at 04:27:35 UTC, Walter Bright wrote:
When has D ever done anything right in your eyes? Just
curious!
[ ... more complaints about D ... ]
So what's
On 7/10/2016 10:21 PM, Ola Fosheim Grøstad wrote:
On Monday, 11 July 2016 at 04:27:35 UTC, Walter Bright wrote:
When has D ever done anything right in your eyes? Just curious!
[ ... more complaints about D ... ]
So what's stopping you from using Scheme?
On 7/9/2016 8:02 PM, Superstar64 wrote:
Would it be possible and a good idea to have a language feature that
allows some exceptions to use error code code generation.
If you want to return an error code, return an error code. No language
feature is required.
On 7/9/16 11:02 PM, Superstar64 wrote:
In terms of performance and code generation exceptions are faster in the
regular path while error codes are faster in the error path.
Would it be possible and a good idea to have a language feature that
allows some exceptions to use error code code
On Sunday, 10 July 2016 at 21:31:57 UTC, Chris Wright wrote:
On Sun, 10 Jul 2016 16:57:49 +, ketmar wrote:
On Sunday, 10 July 2016 at 16:47:31 UTC, Chris Wright wrote:
You do need a try/catch in every annotated function to catch
runtime exceptions like OutOfMemoryError.
as a side note:
On Monday, 11 July 2016 at 04:27:35 UTC, Walter Bright wrote:
On 7/10/2016 10:03 AM, Ola Fosheim Grøstad wrote:
Yes, this has been discussed quite heavily in the past. It is
both
possible and a good idea, but it won't happen. This is quite
typical for
possible and good ideas around here...
On 7/10/2016 10:03 AM, Ola Fosheim Grøstad wrote:
Yes, this has been discussed quite heavily in the past. It is both
possible and a good idea, but it won't happen. This is quite typical for
possible and good ideas around here... :-)
When has D ever done anything right in your eyes? Just
On Sun, 10 Jul 2016 17:19:31 +, phant0m wrote:
> Usually,
> only a calling context can fix the error and continue execution of the
> program. If exception caught by a top level handler, all it can do is
> just a crash.
We separate execution into tasks (which could be messages in SQS, or RPCs
On Sun, 10 Jul 2016 16:57:49 +, ketmar wrote:
> On Sunday, 10 July 2016 at 16:47:31 UTC, Chris Wright wrote:
>> You do need a try/catch in every annotated function to catch runtime
>> exceptions like OutOfMemoryError.
>
> as a side note: it is even not guaranteed that one *can* catch Error.
On Sunday, 10 July 2016 at 03:02:31 UTC, Superstar64 wrote:
In terms of performance and code generation exceptions are
faster in the regular path while error codes are faster in the
error path.
Would it be possible and a good idea to have a language feature
that allows some exceptions to use
On Sunday, 10 July 2016 at 17:19:31 UTC, phant0m wrote:
Personally, I don't understand the need for exceptions at all.
Usually, only a calling context can fix the error and continue
execution of the program. If exception caught by a top level
handler, all it can do is just a crash. Moreover,
On Sunday, 10 July 2016 at 03:02:31 UTC, Superstar64 wrote:
In terms of performance and code generation exceptions are
faster in the regular path while error codes are faster in the
error path.
Would it be possible and a good idea to have a language feature
that allows some exceptions to use
On Sunday, 10 July 2016 at 03:02:31 UTC, Superstar64 wrote:
In terms of performance and code generation exceptions are
faster in the regular path while error codes are faster in the
error path.
Would it be possible and a good idea to have a language feature
that allows some exceptions to use
On Sunday, 10 July 2016 at 16:47:31 UTC, Chris Wright wrote:
You do need a try/catch in every annotated function to catch
runtime exceptions like OutOfMemoryError.
as a side note: it is even not guaranteed that one *can* catch
Error. and it is plainly wrong to try to continue execution after
On Sunday, 10 July 2016 at 06:36:06 UTC, Seb wrote:
On Sunday, 10 July 2016 at 06:31:34 UTC, ketmar wrote:
what i just did read?! O_O
Don't be drunken on the NG! If you take the time to answer, do
so in a friendly and helpful way. Remember that you also
started as a beginner!
Well, I am
On Sun, 10 Jul 2016 07:06:28 +, ketmar wrote:
> it seems that OP wants a kind of compiler switch (or pragma, or
> attribute) to magically turn `throw` into returning some kind of "error
> value". and we already has too much dangerous compiler switches like
> that (even one is too much, and we
On Sunday, 10 July 2016 at 06:36:06 UTC, Seb wrote:
Remember that you also started as a beginner!
no. i was born ideal and all-knowledgeable.
it seems that OP wants a kind of compiler switch (or pragma, or
attribute) to magically turn `throw` into returning some kind of
"error value". and we already has too much dangerous compiler
switches like that (even one is too much, and we have two).
On Sunday, 10 July 2016 at 03:02:31 UTC, Superstar64 wrote:
In terms of performance and code generation exceptions are
faster in the regular path while error codes are faster in the
error path.
Would it be possible and a good idea to have a language feature
that allows some exceptions to use
On Sunday, 10 July 2016 at 06:31:34 UTC, ketmar wrote:
what i just did read?! O_O
Don't be drunken on the NG! If you take the time to answer, do so
in a friendly and helpful way. Remember that you also started as
a beginner!
what i just did read?! O_O
In terms of performance and code generation exceptions are faster
in the regular path while error codes are faster in the error
path.
Would it be possible and a good idea to have a language feature
that allows some exceptions to use error code code generation.
41 matches
Mail list logo
