On Friday, 7 July 2017 at 18:48:31 UTC, Marco Leise wrote:
Am Thu, 06 Jul 2017 13:16:23 +
schrieb Moritz Maxeiner :
That's right, but still one can distill general ideas and leave
implementations details aside. Pretty much like the Platonic
Ideal. Then you look at what the complaints are w
Am Thu, 06 Jul 2017 13:16:23 +
schrieb Moritz Maxeiner :
> On Thursday, 6 July 2017 at 11:01:26 UTC, Marco Leise wrote:
> > Am Thu, 06 Jul 2017 01:31:44 +
> > schrieb Moritz Maxeiner :
> >
> >> But to be clear (and the title and description of any DIP
> >> addressing this should reflect
On Thursday, 6 July 2017 at 14:59:10 UTC, Crayo List wrote:
On Wednesday, 5 July 2017 at 21:05:04 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 5 July 2017 at 15:48:33 UTC, Crayo List wrote:
What happens to the 3000 direct and indirect calls to open() ?
Notice how the 'interface' has not chang
On Wednesday, 5 July 2017 at 21:05:04 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 5 July 2017 at 15:48:33 UTC, Crayo List wrote:
What happens to the 3000 direct and indirect calls to open() ?
Notice how the 'interface' has not changed, only the
implementation.
No, the exception spec is par
On Thursday, 6 July 2017 at 11:01:26 UTC, Marco Leise wrote:
Am Thu, 06 Jul 2017 01:31:44 +
schrieb Moritz Maxeiner :
But to be clear (and the title and description of any DIP
addressing this should reflect this):
These are not checked exceptions, because checked exceptions
would require ba
Am Thu, 06 Jul 2017 01:31:44 +
schrieb Moritz Maxeiner :
> But to be clear (and the title and description of any DIP
> addressing this should reflect this):
> These are not checked exceptions, because checked exceptions
> would require bar to declare its exception set manually.
Yep, absolut
On Thursday, 6 July 2017 at 01:31:44 UTC, Moritz Maxeiner wrote:
---
void foo() throws AException throws BException { ... }
vod bar() { foo(); }
---
works and bar's exception is inferred by the compiler to
contain AException and BException.
But to be clear (and the title and description of an
On Wednesday, 5 July 2017 at 20:35:14 UTC, Marco Leise wrote:
Am Wed, 28 Jun 2017 11:04:58 +
schrieb Moritz Maxeiner :
One could also make an exception for bodyless functions and
allow specification of the exception set *only* there, e.g.
---
// Allow "checked exceptions" for stubs only
v
On Wednesday, 5 July 2017 at 15:48:33 UTC, Crayo List wrote:
What happens to the 3000 direct and indirect calls to open() ?
Notice how the 'interface' has not changed, only the
implementation.
No, the exception spec is part of the interface whether it is in
the function declaration or not.
In general, I'm of the opinion that DLL API should be fully
explicit. It's the only way you can reasonably provide
ABI stability. That means no templates, no attribute inference
and explicit exception lists if the compiler were to used them.
--
Marco
Am Wed, 28 Jun 2017 11:04:58 +
schrieb Moritz Maxeiner :
> One could also make an exception for bodyless functions and allow
> specification of the exception set *only* there, e.g.
>
> ---
> // Allow "checked exceptions" for stubs only
> void foo() throws AException throws BException;
> ---
On Tuesday, 4 July 2017 at 10:14:11 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 3 July 2017 at 20:22:39 UTC, Crayo List wrote:
On Thursday, 29 June 2017 at 21:06:12 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 29 June 2017 at 19:34:22 UTC, Crayo List wrote:
Checked exceptions are a horrible idea
On Monday, 3 July 2017 at 20:22:39 UTC, Crayo List wrote:
On Thursday, 29 June 2017 at 21:06:12 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 29 June 2017 at 19:34:22 UTC, Crayo List wrote:
Checked exceptions are a horrible idea because they leak
internal implementation details as part of the si
On Thursday, 29 June 2017 at 21:06:12 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 29 June 2017 at 19:34:22 UTC, Crayo List wrote:
Checked exceptions are a horrible idea because they leak
internal implementation details as part of the signature of a
method directly and in a transitive manner, w
On Wednesday, June 28, 2017 21:47:56 Nick Sabalausky via Digitalmars-d
wrote:
> On 06/25/2017 01:38 PM, mckoder wrote:
> > I am disappointed that D doesn't have checked exceptions.
>
> Huh? Is it April 1st?
That was kind of my reaction. It has been my impression that while many
folks initially s
On Thursday, 29 June 2017 at 19:34:22 UTC, Crayo List wrote:
Checked exceptions are a horrible idea because they leak
internal implementation details as part of the signature of a
method directly and in a transitive manner, which of course is
one huge aberration!
What do you mean? Exceptions
On Monday, 26 June 2017 at 15:40:19 UTC, mckoder wrote:
Here's the point: with checked exceptions good programmers can
write good code. Without checked exceptions even good
programmers are forced to write bad code.
This statement is logically equivalent to "good code can only be
written wit
On 06/25/2017 01:38 PM, mckoder wrote:
I am disappointed that D doesn't have checked exceptions.
Huh? Is it April 1st?
On Tuesday, 27 June 2017 at 16:54:08 UTC, Sebastien Alaiwan wrote:
adorned with a do-try block, or a try!, or a try?. There is no
way, in this language, to silently throw an exception all the
way to the top level; without paving a super-hiway for it up
through the entire calling tree."
I don'
On Wednesday, 28 June 2017 at 06:31:40 UTC, Biotronic wrote:
On Monday, 26 June 2017 at 19:31:53 UTC, Moritz Maxeiner wrote:
the good *way* to achieve this result would be the following:
- When visiting `startFoo`, the compiler automatically
aggregates all different exceptions it may throw and
On Monday, 26 June 2017 at 19:31:53 UTC, Moritz Maxeiner wrote:
the good *way* to achieve this result would be the following:
- When visiting `startFoo`, the compiler automatically
aggregates all different exceptions it may throw and stores the
resulting set
- If `startFoo` is going to be part
On Wednesday, 28 June 2017 at 02:09:40 UTC, Moritz Maxeiner wrote:
---
static assert (throwsExactly!(foo, AException, BException));
void foo() { ... }
---
One could even go a bit farther and implement a mixin template
using `typeof(this)` and do:
---
void foo()
{
mixin ThrowsExactly!(AE
On Wednesday, 28 June 2017 at 01:35:32 UTC, mckoder wrote:
On Tuesday, 27 June 2017 at 22:56:47 UTC, Moritz Maxeiner wrote:
You mean the very first time you want to call it and you don't
know the exception set yourself by looking at its signature?
Put the call in a nothrow scope and compile th
On Tuesday, 27 June 2017 at 22:56:47 UTC, Moritz Maxeiner wrote:
You mean the very first time you want to call it and you don't
know the exception set yourself by looking at its signature?
Put the call in a nothrow scope and compile the module (which
is fast in D), the compiler will then compl
On Tuesday, 27 June 2017 at 21:47:49 UTC, jag wrote:
On Tuesday, 27 June 2017 at 19:37:24 UTC, Moritz Maxeiner wrote:
As I have pointed out, your example occurs on the *caller*
side, not the *callee* side. The proper solution is not for
the callee to specify which exceptions it may throw, but
On Tuesday, 27 June 2017 at 06:10:52 UTC, Tobias Müller wrote:
I honestly don't understand how people that care a great deal
about expressive type systems can be so opposed to checked
exceptions. After all they wouldn't use 'object' for everything
either.
Tobi
I think there is a threshold.
On Tuesday, 27 June 2017 at 19:37:24 UTC, Moritz Maxeiner wrote:
As I have pointed out, your example occurs on the *caller*
side, not the *callee* side. The proper solution is not for the
callee to specify which exceptions it may throw, but for the
caller to specify which exceptions it allows
On Tuesday, 27 June 2017 at 18:14:47 UTC, jag wrote:
As Tobias mentioned, there are safety implications to "auto"
behavior. In the example below I am using C# and its "var"
feature:
[...]
Your example uses variable type inference, which happens on the
*caller* side, *not* the *callee* side,
As Tobias mentioned, there are safety implications to "auto"
behavior. In the example below I am using C# and its "var"
feature:
class A {
public static Employee getFoo() {
return getPoorPerformingEmployee();
}
}
This is your code, in which you are calling A which was written
by s
On Tuesday, 27 June 2017 at 16:01:37 UTC, mckoder wrote:
On Tuesday, 27 June 2017 at 11:40:02 UTC, Moritz Maxeiner wrote:
It's not at all bad code to write things down that the
compiler could infer, quite the opposite.
Of course it is bad, because the compiler can do it better (no
chance fo
On Tuesday, 27 June 2017 at 10:18:04 UTC, mckoder wrote:
"I think that the belief that everything needs strong static
(compile-time) checking is an illusion; it seems like it will
buy you more than it actually does. But this is a hard thing to
see if you are coming from a statically-typed langu
On Tuesday, 27 June 2017 at 11:40:02 UTC, Moritz Maxeiner wrote:
It's not at all bad code to write things down that the
compiler could infer, quite the opposite.
Of course it is bad, because the compiler can do it better (no
chance for a wrong exception set sans compiler bugs) and faster
th
I think it's important to understand, D is *not* Java.
On Tuesday, 27 June 2017 at 06:10:52 UTC, Tobias Müller wrote:
Moritz Maxeiner wrote:
[...]
Or, more succinct: You must either manually write things down
the
compiler could find out in a fraction of the time via static
analysis, or cheat the system; both cases are bad code.
It's not at all
On Tuesday, 27 June 2017 at 06:10:52 UTC, Tobias Müller wrote:
It's not at all bad code to write things down that the compiler
could infer, quite the opposite.
Writing it down signals _intent_ and the compiler can check if
the implementation is matching the specification which gives
you addit
On Monday, 26 June 2017 at 21:00:24 UTC, Guillaume Boucher wrote:
I would say that the overload without exceptions is the
"standard" one.
The C++ assumption is that exceptions are slow. So what the text
you referenced says is that it provides an alternative mechanism
for situations where you
Moritz Maxeiner wrote:
> [...]
> Or, more succinct: You must either manually write things down the
> compiler could find out in a fraction of the time via static
> analysis, or cheat the system; both cases are bad code.
It's not at all bad code to write things down that the compiler could
infer
On Monday, 26 June 2017 at 17:44:15 UTC, Guillaume Boucher wrote:
On Monday, 26 June 2017 at 16:52:22 UTC, Sebastien Alaiwan
wrote:
Checked exceptions allow a lot more precision about what types
of exceptions a function can throw.
I totally agree that this is a problem with D right now.
This w
On Tuesday, 27 June 2017 at 00:29:53 UTC, crimaniak wrote:
On Monday, 26 June 2017 at 19:31:53 UTC, Moritz Maxeiner wrote:
And the good *way* to achieve this result would be the
following:
- When visiting `startFoo`, the compiler automatically
aggregates all different exceptions it may throw
On Monday, 26 June 2017 at 19:31:53 UTC, Moritz Maxeiner wrote:
And the good *way* to achieve this result would be the
following:
- When visiting `startFoo`, the compiler automatically
aggregates all different exceptions it may throw and stores the
resulting set
- If `startFoo` is going to be
On Sunday, 25 June 2017 at 17:38:14 UTC, mckoder wrote:
I am disappointed that D doesn't have checked exceptions.
Warning, Google translate is used! (sorry)
I fully support mckoder with regard to exceptions. This is a
great advantage of Java. I think, the problem with the
introduction of ver
On Monday, 26 June 2017 at 18:42:24 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 26 June 2017 at 17:44:15 UTC, Guillaume Boucher
wrote:
Java uses A, Rust/Go use B. C++ uses B to some extend (e.g.
in std::experimental::filesystem).
The C++17 filesystem api provides two alternatives, the
standar
On Monday, 26 June 2017 at 17:50:47 UTC, Moritz Maxeiner wrote:
I have tried using such Monads in D, but in the end it always
ended up being too verbose or too hard to read compared to
using exceptions or even simple error codes (with 0 == no
error).
I haven't tried that yet, tbh. visit is n
On Monday, 26 June 2017 at 18:31:50 UTC, jag wrote:
On Monday, 26 June 2017 at 17:43:08 UTC, Moritz Maxeiner wrote:
Here's the point: with checked exceptions good programmers
can write good code.
With checked exceptions any programmer is forced to
a) annotate every single function with the com
On Monday, 26 June 2017 at 17:44:15 UTC, Guillaume Boucher wrote:
Java uses A, Rust/Go use B. C++ uses B to some extend (e.g. in
std::experimental::filesystem).
The C++17 filesystem api provides two alternatives, the standard
filesystem_error exception and an output-paramater for capturing
o
On Monday, 26 June 2017 at 17:43:08 UTC, Moritz Maxeiner wrote:
Here's the point: with checked exceptions good programmers can
write good code.
With checked exceptions any programmer is forced to
a) annotate every single function with the complete aggregate
of the exceptions that may be thrown
On Monday, 26 June 2017 at 17:44:15 UTC, Guillaume Boucher wrote:
It is very well possible to use option B in D. The most
convenient one is making functions nothrow and use
Algebraic!(T, ErrorCode), or, for void functions, have a
parameter "ref ErrorCode".
If all functions in Phobos would eith
On Monday, 26 June 2017 at 16:52:22 UTC, Sebastien Alaiwan wrote:
Checked exceptions allow a lot more precision about what types
of exceptions a function can throw.
I totally agree that this is a problem with D right now. If you
want to catch all errors, how are you supposed to remember what
On Monday, 26 June 2017 at 15:40:19 UTC, mckoder wrote:
On Monday, 26 June 2017 at 15:15:54 UTC, Steven Schveighoffer
wrote:
No, checked exceptions leads to this (maybe not for you, but
for 90% of developers out there):
void foo()
{
functionWithException();
}
compiler: foo throws, and yo
On Monday, 26 June 2017 at 16:35:51 UTC, jmh530 wrote:
Just curious: how are checked exceptions different from setting
nothrow as the default? Like you would have to write:
void foo() @maythrow
{
functionWithException();
}
So for instance, you could still use your "//shut up compiler"
code
On Monday, 26 June 2017 at 16:35:51 UTC, jmh530 wrote:
Just curious: how are checked exceptions different from setting
nothrow as the default? Like you would have to write:
void foo() @maythrow
{
functionWithException();
}
So for instance, you could still use your "//shut up compiler"
code
On Monday, 26 June 2017 at 15:15:54 UTC, Steven Schveighoffer
wrote:
No, checked exceptions leads to this (maybe not for you, but
for 90% of developers out there):
void foo()
{
functionWithException();
}
compiler: foo throws, and you need to handle or declare the
exceptions it throws
v
On Monday, 26 June 2017 at 15:15:54 UTC, Steven Schveighoffer
wrote:
void foo()
{
try {
functionWithException();
} catch(Exception e) {} // shut up compiler
}
So it ends up defeating the purpose. The exception is not
properly handled, either inside or outside the function.
That's a
On Monday, 26 June 2017 at 15:15:54 UTC, Steven Schveighoffer
wrote:
No, checked exceptions leads to this (maybe not for you, but
for 90% of developers out there):
void foo()
{
functionWithException();
}
compiler: foo throws, and you need to handle or declare the
exceptions it throws
v
important thing
missing in C++ and C#. Around the time C# was released there was a lot
of debate around the topic of checked vs unchecked exceptions and this
created an impression that Java's use of checked exceptions was
"controversial". In fact it is a feature every modern l
On Sunday, 25 June 2017 at 18:00:46 UTC, Eugene Wissner wrote:
http://forum.dlang.org/post/ullvxbfqeuztwecxc...@forum.dlang.org
As suggested by the post in above link I searched for "Walter
checked exceptions". I found a few posts where Walter points to
an article written by Bruce Eckel. Tho
On Sunday, 25 June 2017 at 17:38:14 UTC, mckoder wrote:
Exceptions that can be thrown by a method should be part of the
contract of that method. Changing the list of the list of
exceptions that can be thrown by a method is just like changing
the parameters of the method. This is something that
ely in all these
languages I can say with confidence that checked exceptions is
the most important thing missing in C++ and C#. Around the time
C# was released there was a lot of debate around the topic of
checked vs unchecked exceptions and this created an impression
that Java's use of che
C++ and C#. Around the time C# was
released there was a lot of debate around the topic of checked vs
unchecked exceptions and this created an impression that Java's
use of checked exceptions was "controversial". In fact it is a
feature every modern language should have.
Exception
59 matches
Mail list logo
