On Monday, 1 April 2013 at 21:39:18 UTC, Dmitry Olshansky wrote:
01-Apr-2013 23:46, Lars T. Kyllingstad пишет:
On Monday, 1 April 2013 at 18:40:48 UTC, Dmitry Olshansky
wrote:
2. ProcessException is IMHO a system exception. Plus some
RTOses
systems may not have processes in the usaul POSIX sense. It
needs some
thought.
Well, I *don't* think ProcessException is a SystemException.
:) And if
druntime/Phobos is to be used on OSes that don't have
processes, there
are other adaptations that have to be made that are probably
more
fundamental.
Okay. I guess all of this goes to "Embedded D"/"D Lite" kind of
spec.
Last thing - why separating ThreadException vs ProcessException
and should they have some base class? Just asking to see the
rationale behind it that is missing from DIP currently.
Well, I hadn't even considered that the same exception could be
used for both. I see the similarity between processes and
threads, but I also think there is a difference in how/when/where
you want to deal with errors related to them. Say you have a
function that starts a new process and then spawns a new thread
to monitor it, and then the function fails for some reason. This
could be something you'd want to deal with on different levels,
as a ProcessException could simply be that you got the wrong
executable name, while a ThreadException would usually point to a
much deeper issue.
4. A quiz as an extension of 3 - where a e.g. serial port
exceptions
would fit in this hierarchy? Including Parity errors, data
overrun etc.
Let's think a bit ahead and pick names wisely.
Maybe turn NetworkException --> Comm(unication)Exception, I
dunno.
Good question, I dunno either. :) I agree we should think
about it.
I have thought some more about it, and a basic serial comms error
should probably be an IOException. An error in a higher-level
serial protocol, on the other hand, would be a NetworkException,
and then the name doesn't suck so much. CommException may still
be better though, or maybe ProtocolException.
8. For IOExcpetion we might consider adding an indication on
which
file handle the problem happened and/or if it's
closed/invalid/"mostly
fine" that.
Which form do you suggest that such an indicator should take?
That's the trick - I hoped somebody will just say "aha!" and
add one :)
The internal handle is hard to represent other then ... some
platform specific integer value. There goes generality... Other
then this there is a potential to stomp on feet of higher-level
abstraction on top of that handle.
That last bit makes me reconsider the idea. While I see some
potential use for it I suspect it's too niche to fit in the
general hierarchy.
Bear in
mind that it should be general enough to cover all, or at
least most,
kinds of I/O exceptions.
Adding a Kind that states one of:
out-of-data (read empty file)
illegalOp (reading closed file, writing read-only file/socket)
interrupted (operation was canceled by OS, connection forcibly
closed, disk ejected etc.)
hardFault (OS reports hardware failure)
These are good suggestions, and seem general enough.
Lars
